From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Upper planner pathification |
Date: | 2016-03-03 20:52:26 |
Message-ID: | 5195.1457038346@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Mar 3, 2016 at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Thanks. As I told Teodor last night, I can't reproduce a performance
>> issue here with pgbench-style queries. Do you have any thoughts about
>> how we might satisfy ourselves whether there is or isn't a performance
>> problem?
> One idea might be to run a whole bunch of queries and record all of
> the planning times, and then run them all again and compare somehow.
> Maybe the regression tests, for example.
That sounds like something we could do pretty easily, though interpreting
the results might be nontrivial. There will, I expect, be a mix of
queries that do get slower as well as those that don't. As long as the
former are just queries that we hope to get some plan-quality win on,
I think that's an acceptable result ... but we'll need to record enough
data to tell what we're looking at.
For starters, I'll try logging whether the query has setops, grouping,
aggregation, window functions, and try to measure planning time change
in each of those categories.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-03 21:08:56 | Re: TAP / recovery-test fs-level backups, psql enhancements etc |
Previous Message | Robert Haas | 2016-03-03 20:29:36 | Re: WIP: Upper planner pathification |