Re: New design for FK-based join selectivity estimation

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2016-06-13T21:09:43Z
Lists: pgsql-hackers

Attachments

Hi,

Attached is a reworked patch, mostly following the new design proposal 
from this thread.

I'm not entirely happy with the code, but it's the best I've been able 
to come up with by now and I won't be able to significantly improve that 
due to travel over. Inevitably there will be issues in the code, and if 
there's a chance of fixing them I'll do my best to do that over the 
evenings at a hotel.

The filtering and matching to eclasses / join quals is triggered from 
planmain.c - I believe this is the right place and that those pieces are 
reasonably solid.

The estimation still happens in costsize.c, of course, but was modified 
to use the pre-matched info. I have my doubts about this part, and I'm 
sure Tom had something less complex / more efficient in mind (using the 
pre-matched info).


regards

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

Commits

  1. Fix FK-based join selectivity estimation for semi/antijoins.

  2. Restore foreign-key-aware estimation of join relation sizes.