|From:||Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Patch: ResourceOwner optimization for tables with many partitions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Here is my fix for item 4.
On Thu, 10 Dec 2015 11:37:23 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 9, 2015 at 8:30 AM, Aleksander Alekseev
> <a(dot)alekseev(at)postgrespro(dot)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.
|Next Message||Andres Freund||2015-12-14 11:49:41||Re: psql tab completion bug for ALL IN TABLESPACE|
|Previous Message||Michael Paquier||2015-12-14 11:44:20||Re: psql tab completion bug for ALL IN TABLESPACE|