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
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 |