From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Andreas Seltenreich <seltenreich(at)gmx(dot)de> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: [sqlsmith] Failed to generate plan on lateral subqueries |
Date: | 2015-12-13 00:04:34 |
Message-ID: | CAM-w4HMgjyhf13AmxY_6x+KoKDrcNbY5+gCfL4r1p95e_ax9aw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich <seltenreich(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Ramsey | 2015-12-13 00:17:06 | [PATCH] PostGIS Doc Urls |
Previous Message | Tom Lane | 2015-12-12 23:42:16 | Re: Using a single standalone-backend run in initdb (was Re: Bootstrap DATA is a pita) |