Skip site navigation (1) Skip section navigation (2)

Re: Join optimization for inheritance tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: nborisov(at)asterdata(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, Herodotos Herodotou <Herodotos(dot)Herodotou(at)asterdata(dot)com>, Eric Friedman <Eric(dot)Friedman(at)asterdata(dot)com>, John Cieslewicz <John(dot)Cieslewicz(at)asterdata(dot)com>, Dheeraj Pandey <Dheeraj(dot)Pandey(at)asterdata(dot)com>
Subject: Re: Join optimization for inheritance tables
Date: 2009-06-26 23:25:13
Message-ID: 11854.1246058713@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Nedyalko Borisov <nedyalko(at)asterdata(dot)com> writes:
> In summary, we are making two suggestions:
> 1. Extend the optimizer to consider joins between child tables when hierarchies are joined together.

We already handle this for the case where the join is nestloop with
inner index scan, and I'm not convinced that there's any real gain to be
had for other join types.

> 2. Add the "Empty Check Constraint", which would enforce that a particular table is to remain empty.

The trouble with that is that a constraint that doesn't propagate to its
child tables is a weird beast that I'd just as soon not invent.

We are currently thinking about inventing an explicit notion of
partitioned tables.  If we had that, it would be reasonable to have
a special kind of "parent" table for a partitioned set and refuse to
allow any data in that relation.  But I'm not excited about contorting
the general constraint mechanism in the way that would be necessary to
express this as a constraint.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-06-28 01:49:51
Subject: Re: [HACKERS] pull raw text of a message by message-id
Previous:From: Bernd HelmleDate: 2009-06-26 22:39:09
Subject: Re: [PATCH] [v8.5] Security checks on largeobjects

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group