On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich <seltenre...@gmx.de> wrote: > I currently set statement_timeout to 1s to avoid wasting time letting > postgres crunch numbers. Less than 0.5% of the queries run into this > timeout.
I wonder if any of these timeouts would be interesting to look at. Some may just be very large queries that will take a few seconds to plan but others may be queries that are uncovering N^2 algorithms or even conceivably loops that are not terminating. When you hit the timeout is this implemented in your fuzzer or using statement_timeout? If the former, can you add a statement_timeout of just short of the timeout in the fuzzer and find cases where the planner might not be calling CHECK_FOR_INTERRUPTS frequently enough? > > Do you have coverage data for the corpus? > > I do have some older numbers for line coverage from before the recent grammar > extension: If you have a corpus of queries in a simple format it would be pretty convenient to add them in a regression test and then run make coverage to get html reports. Did you publish the source already? I haven't been following all along, sorry if these are all answered questions. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
