Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I think the default pgbench queries are too simple to have any possible
>> benefit from this patch. It does look like you're seeing some extra
>> planning time, which I think is likely due to redundant construction
>> of PathTargets. The new function set_pathtarget_cost_width() is not
>> very cheap, and in order to minimize the delta in this patch I did
>> not worry much about avoiding duplicate calls of it. That's another
>> thing in a long list of things to do later ;-). There might be other
>> pain points I haven't recognized yet.
> Yikes. The read-only test is an 0.5% hit which isn't great, but the
> read-write test is about 5% which I think is clearly not OK. What's
> your plan for doing something about that?
I do plan to take a look at it. Obviously, anything that *does* benefit
from this patch is going to see some planning slowdown as a consequence
of considering more Paths. But ideally, a query that has no grouping/
aggregation/later steps wouldn't see any difference. I think we can
get to that --- but I'd rather not complicate v1 with the hacks that
will probably be required.
(My first thought about how to fix that is to not force
set_pathtarget_cost_width to be done immediately on PathTarget
construction, but make it a decouplable step. I believe that
set_pathtarget_cost_width is only expensive if it's run before
query_planner runs, and we can probably finagle things so that we do not
really care about the cost/width attached to targets made before that.
But this all depends on profiling that I've not done yet...)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
