On Wed, 2007-04-04 at 14:20 +0200, Markus Schiltknecht wrote: > Both proposals do not have much to do with the missing multi-table > indices. It's clear to me that we have to implement those someday, > anyway.
I agree with much of your post, though this particular point caught my eye. If you'll forgive me for jumping on an isolated point in your post: Multi-table indexes sound like a good solution until you consider how big they would be. The reason we "need" a multi-table index is because we are using partitioning, which we wouldn't be doing unless the data was fairly large. So the index is going to be (Num partitions * fairly-large) in size, which means its absolutely enormous. Adding and dropping partitions also becomes a management nightmare, so overall multi-table indexes look unusable to me. Multi-table indexes also remove the possibility of loading data quickly, then building an index on the data, then adding the table as a partition - both the COPY and the CREATE INDEX would be slower with a pre-existing multi-table index. My hope is to have a mechanism to partition indexes or recognise that they are partitioned, so that a set of provably-distinct unique indexes can provide the exact same functionlity as a single large unique index, just without the management nightmare. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
