Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
От | Jaime Casanova |
---|---|
Тема | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Дата | |
Msg-id | 3073cc9b0811270601m6a7691dcg5f2ea6d4172b0d38@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 ("Robert Haas" <robertmhaas@gmail.com>) |
Ответы |
Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
|
Список | pgsql-hackers |
On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas <robertmhaas@gmail.com> 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
В списке pgsql-hackers по дате отправления: