Re: PATCH: use foreign keys to improve join estimates v1 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: PATCH: use foreign keys to improve join estimates v1
Date
Msg-id CANP8+j+3wP81B01BnQAHw3qpW=nt_OUTZy7bA8ddjiz9DoWQjg@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: use foreign keys to improve join estimates v1  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: PATCH: use foreign keys to improve join estimates v1  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On 14 March 2016 at 19:42, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
Hi,

On 03/14/2016 02:12 PM, David Steele wrote:
Hi Thomas,
...
I don't think it would be clear to any reviewer which patch to apply
even if they were working.  I'm marking this "waiting for author".

Yeah. Rebasing the patches to current master was simple enough (there was just a simple #include conflict), but figuring out which of the patches is review-worthy was definitely difficult.

I do believe David's last patch is the best step forward, so I've rebased it, and made some basic aesthetic fixes (adding or rewording comments on a few places, etc.)

I'd like to split this into 2 patches
1) Add FK info to relcache
2) use FK info in planner

Would the credit for this be 1) Tomas, 2) Tomas + David ?

I'd be inclined to see a little more explanatory docs on this.

Have we done any tests on planning overhead for cases where multiple FKs exist?

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Alex Shulgin
Date:
Subject: Re: More stable query plans via more predictable column statistics