On 3/18/15 8:26 AM, Robert Haas wrote:
In
fact, EnterpriseDB has run into a number of customer situations where
planning time even for non-inheritance queries is substantially higher
than, shall we say, a competing commercial product.
If it's the commercial product I'm thinking of, they use
On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This would have one significant drawback, which is that planning for
large inheritance trees (many children) would probably get noticeably
slower. (But in the common case that constraint exclusion limits a
query to scanning
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, you're ignoring the prospect of getting better estimates and hence
better plans through having stats that dynamically adapt to the set of
partitions being scanned. Given the
For some reason, I didn't get Tom's email, only this reply.
On Tue, Mar 17, 2015 at 3:44 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On 2015/03/17 5:18, Tom Lane wrote:
A few days ago I posted a very-much-WIP patch for making the planner
dynamically combine statistics for each member
Robert Haas robertmh...@gmail.com writes:
For some reason, I didn't get Tom's email, only this reply.
On 2015/03/17 5:18, Tom Lane wrote:
This would have one significant drawback, which is that planning for
large inheritance trees (many children) would probably get noticeably
slower. (But in
On 2015/03/17 5:18, Tom Lane wrote:
A few days ago I posted a very-much-WIP patch for making the planner
dynamically combine statistics for each member of an appendrel:
http://www.postgresql.org/message-id/22598.1425686...@sss.pgh.pa.us
That patch was only intended to handle the case of an
A few days ago I posted a very-much-WIP patch for making the planner
dynamically combine statistics for each member of an appendrel:
http://www.postgresql.org/message-id/22598.1425686...@sss.pgh.pa.us
That patch was only intended to handle the case of an appendrel generated
by a UNION ALL
