Re: [HACKERS] Regression in join selectivity estimations when usingforeign keys - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] Regression in join selectivity estimations when usingforeign keys
Date
Msg-id CAKJS1f8Bpw0d8Ciz1feV9Oq5NsN+dW=92xMnvaKgPbQQ63Yr+Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Regression in join selectivity estimations when usingforeign keys  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Regression in join selectivity estimations when using foreign keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 22 May 2017 at 16:10, David Rowley <david.rowley@2ndquadrant.com> wrote:
> I also just noticed that I don't think I've got ANTI join cases
> correct in the patch I sent. I'll look at that now.

I've attached an updated patch.

This one is much less invasive than my original attempt.

There are two fundamental changes here:

1) OUTER joins now use the foreign key as proof that the join
condition must match.
2) selectivity of nullfrac for null valued columns for OUTER joins is
no longer taken into account. This is now consistent with INNER joins,
which might not be perfect, but it's less surprising. If this is a
problem then we can consider applying something like my 0002 patch
above, however that can mean that nulls are double counted if there
are any other strict clauses which are not part of the foreign key
constraint, so that idea is not perfect either.

In addition to those two things, the poor selectivity estimation in my
original email is also fixed.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: [HACKERS] ECPG: pg_type.h file is not synced
Next
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] Create subscription with `create_slot=false` andincorrect slot name