Re: Patch: ResourceOwner optimization for tables with many partitions
| От | Aleksander Alekseev |
|---|---|
| Тема | Re: Patch: ResourceOwner optimization for tables with many partitions |
| Дата | |
| Msg-id | 20151214144722.5812c52c@fujitsu обсуждение исходный текст |
| Ответ на | Re: Patch: ResourceOwner optimization for tables with many partitions (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Patch: ResourceOwner optimization for tables with many partitions
|
| Список | pgsql-hackers |
Hello, Robert Here is my fix for item 4. Best regards, Aleksander On Thu, 10 Dec 2015 11:37:23 -0500 Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Dec 9, 2015 at 8:30 AM, Aleksander Alekseev > <a.alekseev@postgrespro.ru> wrote: > > Hello, Robert > > > > Thanks for your review. I believe I fixed items 1, 2 and 3 (see > > attachment). Also I would like to clarify item 4. > > > >> 4. It mixes together multiple ideas in a single patch, not only > >> introducing a hashing concept but also striping a brand-new layer > >> of abstraction across the resource-owner mechanism. I am not sure > >> that layer of abstraction is a very good idea, but if it needs to > >> be done, I think it should be a separate patch. > > > > Do I right understand that you suggest following? > > > > Current patch should be split in two parts. In first patch we create > > and use ResourceArray with array-based implementation (abstraction > > layer). Then we apply second patch which change ResourceArray > > implementation to hashing based (optimization). > > Well, sorta. To be honest, I think this patch is really ugly. If we > were going to do this then, yes, I would want to split the patch into > two parts along those lines. But actually I don't really want to do > it this way at all. It's not that I don't want the performance > benefits: I do. But the current code is really easy to read and > extremely simple, and this changes it into something that is a heck of > a lot harder to read and understand. I'm not sure exactly what to do > about that, but it seems like a problem. >
Вложения
В списке pgsql-hackers по дате отправления: