Re: [HACKERS] New partitioning - some feedback
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] New partitioning - some feedback |
Дата | |
Msg-id | CA+TgmoYuJwCZ7229+3Zx9KrR52uxgFp=h2zD0nB=n_Zt4da03w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] New partitioning - some feedback (Vik Fearing <vik.fearing@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Jul 18, 2017 at 2:26 AM, Vik Fearing <vik.fearing@2ndquadrant.com> wrote: > On 07/07/2017 02:02 AM, Mark Kirkwood wrote: >> I'd prefer *not* to see a table and its partitions all intermixed in the >> same display (especially with nothing indicating which are partitions) - >> as this will make for unwieldy long lists when tables have many >> partitions. Also it would be good if the 'main' partitioned table and >> its 'partitions' showed up as a different type in some way. > > I've just read through this thread, and I'm wondering why we can't just > have something like \set SHOW_PARTITIONS true or something, and that > would default to false. We could, and that would have the advantage of letting people set a default. On the other hand, if you want to override the default behavior just once, adding a modifier character is a lot less typing than issuing \set, retyping your command, and issuing \set again to change it back. So I don't know which is better. My main point is that it's too late to be making changes upon which we do not have a clear consensus. I reject the argument that v11 will be too late to make this change. Now that we have partitioning, I believe there will be zillions of things that need to be done to improve it further; several of those things already have proposed patches; this can be another one of those things. If we rush something in now and it turns out that it isn't well-liked, we may well end up with one behavior for v<10, another behavior for v=10, and a third behavior for v>10. Better to wait and make the change later when we have a few more data points. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: