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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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