From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Yuto Hayamizu <y(dot)hayamizu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Overestimated filter cost and its mitigation |
Date: | 2017-11-07 21:48:33 |
Message-ID: | 29346.1510091313@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:
> I think it would be a good idea, as Thomas says, to order the qual
> clauses at an earlier stage and then remember our decision. However,
> we have to think about whether that's going to increase planning time
> in a noticeable way. I wonder why we currently postpone this until
> such a late phase of planning.
Because (1) up to now there's been no need to consider the qual ordering
till later, and (2) re-doing that sort for each path seemed unduly
expensive. If we're to try to estimate whether later quals will be
reached, then sure the ordering becomes important. I'm still concerned
about (2) though. If there were a way to pre-sort the quals once for
all paths, the problem goes away, but I don't think that works ---
indexscans may segregate some quals, and in join cases different paths
will actually have different sets of quals they need to check depending
on the join order.
So the bottom line here is how much is it going to cost us to add this
additional refinement in cost estimation, and is it worth it given our
extremely poor level of accuracy in expression cost estimation. Color
me dubious.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-11-07 21:55:34 | Re: Parallel Hash take II |
Previous Message | Robert Haas | 2017-11-07 21:48:16 | Re: Refactor handling of database attributes between pg_dump and pg_dumpall |