On May 6, 2010, at 16:38 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> What lies at the heart of this problem is the lack of multi-table
>> indices and hence multi-table unique constraints in postgres. AFAIK
>> with those in place the rest amounts to the removal of ONLY from the
>> constraint check queries plus some code to propagate constraint
>> triggers to child tables.
>
> Well, the lack of multi-table indexes certainly is the heart of the
> problem, but I'm not sure that inventing such a thing is the solution.
> Quite aside from the implementation difficulties involved in it,
> doing things that way would destroy some of the major reasons to
> partition tables at all:
>
> * the index grows as the size of the total data set, it's not limited
> by partition size
>
> * can't cheaply drop one partition any more, you have to vacuum the
> (big) index first
>
> * probably some other things I'm not thinking of at the moment.
>
> I think the real solution is to upgrade the partitioning infrastructure
> so that we can understand that columns are unique across the whole
> partitioned table, when the partitioning is done on that column and each
> partition has a unique index.
True, for partitioned tables multi-table indices reintroduce some of the performance problems that partitioning is
supposedto avoid.
But OTOH if you use table inheritance as a means to map data models (e.g. EER) more naturally to SQL, then multi-table
indiceshave advantages over the partitioning-friendly solution you sketched above.
With a multi-table index, SELECT * FROM PARENT WHERE ID=?? has complexity LOG(N*M) where M is the number of tables
inheritingfrom PARENT (including PARENT itself), and N the average number of rows in these tables. With one index per
child,the complexity is M*LOG(N) which is significantly higher if M is large. Constraint exclusion could reduce that to
LOG(N),but only if each child is has it's own private ID range which precludes ID assignment from a global sequence and
hencemakes ID assignment much more complex and error-prone.
Anyway, I was wondering why we need guaranteed uniqueness for FK relationships anyway. Because if we don't (which I
didn'tcheck prior to posting this I must admit), then why can't we simply remove the "ONLY" from the RI queries and let
ALTERTABLE attach the RI triggers not only to the parent but also to all children. What am I missing?
best regards,
Florian Pflug
