Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats
Date: 2017-04-05 23:20:36
Message-ID: CAKJS1f8eSgpHhZOMYnhmYv0cSh4tGfKvdq=B8g+WJFVgaXzzfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 6 April 2017 at 10:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> Collect and use multi-column dependency stats
>
> The buildfarm is unhappy about the fact that this changed the API
> for clauselist_selectivity(). I am not convinced that that change
> was a good idea, so before telling FDW authors that they need to
> change their code, I'd like to hear a defense of the API change.
> Why not just use the existing varRelid parameter for that? Why
> is there an assumption that only one rel's extended stats will
> ever be of interest? This function does get used for join clauses.

Because varReliId is often passed in as 0, and that meant we'd have to
write some code to check of the clause was made up of RestrictInfos
from a single relation or not, and look for extended stats on that
singleton rel. Given the number of times this function gets called
during planning, especially so with queries involving many joins, I
think it's best to not have to extract the correct relids each time. I
coded it that way to reduce the overhead during planning, which is
something that often comes up with planner patches.

FWIW, I found this function being called 72 times in a 5 way join
search problem.

Perhaps there is a nicer way to do this, I just couldn't think of it.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-04-05 23:33:03 Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats
Previous Message Tom Lane 2017-04-05 22:48:57 Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2017-04-05 23:24:08 Re: PATCH: recursive json_populate_record()
Previous Message Andres Freund 2017-04-05 23:16:40 Re: LWLock optimization for multicore Power machines