Few suggestions towards further reducing some SQLs
While trying to narrow down a bug, I saw that SQLReduce could do a little better.
Original SQLReduce output (sample provided):
SELECT WHERE Fn1 @@ Fn2(Fn3,Fn4)
This could be shortened to:
SELECT WHERE Fn2(Fn3,Fn4)::TEXT::BOOLEAN;
Although not possible in all cases, it could be further shortened to:
SELECT Fn2(Fn3,Fn4);
For e.g.
While trying to narrow down a plv8 bug, I saw that SQLReduce could do a little better. These could be argued to be separate suggestions, but they came out of the same triaging, and so thought I'd merge them here for simplicity.
Original SQLReduce output:
Pretty-printed minimal query:
SELECT
WHERE pg_catalog.pg_export_snapshot() @@ pg_catalog.ts_rewrite(pg_catalog.websearch_to_tsquery(pg_catalog.plv8_version()),
pg_catalog.current_query())
Seen: 71 items, 21722 Bytes
Iterations: 132
Runtime: 104.848 s, 0.7 q/s
Possible improvements
Remove schemaname Once we've narrowed down the issue, (subjective but) it may be simpler on the eye to remove the schema-names.
SELECT WHERE pg_export_snapshot() @@ ts_rewrite(websearch_to_tsquery(plv8_version()), current_query());
Try constants
Sometimes even for volatile functions, the function is there just to emit a string. Any string.
SELECT WHERE 'aaa' @@ ts_rewrite(websearch_to_tsquery(plv8_version()), current_query());
Finally
An option could be to try either side of the operator directly in the SELECT clause:
SELECT ts_rewrite(websearch_to_tsquery(timeofday()), current_query());
p.s.: Love this tool. Thanks for working on this. I am not a dev, but if there isn't much traction on the idea in the coming days, I'll try to submit a patch in a few weeks.