Re: Should we add GUCs to allow partition pruning to be disabled?
От | Alvaro Herrera |
---|---|
Тема | Re: Should we add GUCs to allow partition pruning to be disabled? |
Дата | |
Msg-id | 20180510021724.2k5csd7z6pkfot7q@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Should we add GUCs to allow partition pruning to be disabled? (David Rowley <david.rowley@2ndquadrant.com>) |
Список | pgsql-hackers |
David Rowley wrote: > On 10 May 2018 at 14:01, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > I'm thinking something a bit more radical. First, since partition > > pruning is the future and constraint exclusion is soon to be a thing of > > the past, we should describe pruning first, and then describe exclusion > > in terms of pruning. > > But... that's not true. The chapter describes inheritance partitioned > tables too, and we're not getting rid of constraint exclusion because > it's needed for those. Oh, I'm sure it is, but nobody is going to set up new inheritance partitioned tables anymore, except people who pg_upgrade from older releases. (And while I haven't tried, I'm sure it's possible to migrate from old-style to new-style partitioned tables without incurring full table rewrites, with little downside and lots to gain.) Now, maybe you argue that we could have a structure like this instead: 5.10.1. Overview 5.10.2. Declarative Partitioning 5.10.3. Partition Pruning 5.10.4. Implementation Using Inheritance 5.10.5. Constraint Exclusion I wouldn't oppose that. > However, that might not mean your patch has to be changed. I'd better > have a look... Thanks :-) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: