Hi,
On 05/05/2016 04:48 PM, David Rowley wrote:
On 5 May 2016 at 16:04, David Rowley <david.row...@2ndquadrant.com> wrote:
I've started making some improvements to this, but need to talk to
Tomas. It's currently in the middle of his night, but will try to
catch him in his morning to discuss this with him.
Ok, so I spoke to Tomas about this briefly, and he's asked me to
send in this patch. He didn't get time to look over it due to some
other commitments he has today.
Thanks!
>
I do personally feel that if the attached is not good enough, or not
very close to good enough then probably the best course of action is
to revert the whole thing. I'd much rather have this out than to
feel some responsibility for someone's performance problems with
this feature.
>
I share this opinion. If the approach proposed here is deemed not good
enough, then +1 to revert.
I think we can further limit the impact by ignoring foreign keys on a
single column, because the primary goal of the patch is improving
estimates with multi-column FKs (and matching joins). I'd argue that 99%
of the FKs in practice is single-column ones, but sure - if you have a
database with many multi-column FKs this won't help.
I think it's also important to point out that whatever solution we
choose, it should probably allow us to relax some of the restrictions in
the future. For example, with a FK on 3 columns, the current patch only
handles a "full match" joins, with conditions on all three columns. But
it may be possible to also improve estimates on just two columns - the
current patch does not do that, as that needs definitely further more
thought and discussion.
>
But I also do feel that the patch allows a solution to a big problem
that we currently have with PostgreSQL, which there's any easy
workarounds for... that's multi-column join estimates.
In a sense, yes. FKs allow us to improve estimates for a fairly narrow
case of multi-column estimates - joins matching multi-column FKs. And
for this (not entirely narrow) case they are actually more accurate and
way cheaper than e.g. histograms or MCV lists (at least in the
multi-column case).
FWIW the current multivariate stats patch does not even try to mess with
joins, as it's quite complicated in the multi-column case.
In the attached I've left the GUC remaining. The reason for the GUC
is for testing purposes and it should be removed before release. It
should likely be documented though, even if we're planning to remove
it later. I've not gotten around to that in this patch though.
Yes, removal of the GUC should go to the Open Items list.
I'd also like to make it clear that all the shitty parts of the patch
are my fault, not David's. His name is on the patch as he provided a lot
of useful ideas, pieces of code and feedback in general. But it was up
to me to craft the final patch - and I clearly failed to do so. I think
David still feels responsible for the patch as he made a lot of effort
to salvage it over the last few days, so I'd like to set the record
straight.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
