On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas <[EMAIL PROTECTED]> wrote: > > The semantics of PARTITION ON (<expr>) are unclear to me. I was > thinking maybe it would make sense to do something like: > > CREATE PARTITION <name> ON <table> WHERE <expr> >
At first look seems nice but s Gregory said the ideal would be to identify the key partition. > > I like the idea of using table inheritance as a foundation for this > feature, but I think it's not going to be very useful for real-world > applications without cross-table indexes. Suppose for example that I > have five years worth of data (thus, 60 partitions) and each > transaction has a unique identifier of some sort that is unrelated to > the date. It's bad enough that a query like this has to check every > partition: > you haven't. the WHERE clause in your hipotetical CREATE PARTITION should create a check constraint on the child (inherited) table and if you have constraint_exclusion to on you will check just the partition(s) that match with the check constraint. > > What's even worse (at least IMHO) is that there's no way to use > transaction (uuid) as a reference for a foreign key. > not directly, but you always can create a trigger instead of the foreign key constraint... mmm...the docs says that there is no good workaround, what about mention a trigger? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
