Re: sortsupport for text - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sortsupport for text
Date
Msg-id CA+TgmoZiLUCHFBGeidigg1-4nzcd5XsBFVw7HgeLfV9Uy65drw@mail.gmail.com
Whole thread Raw
In response to Re: sortsupport for text  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sortsupport for text
List pgsql-hackers
On Fri, Jun 15, 2012 at 12:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <peter@2ndquadrant.com> writes:
>> On 14 June 2012 19:28, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I thought that doubling repeatedly would be overly aggressive in terms
>>> of memory usage.
>
>> I fail to understand how this sortsupport buffer fundamentally differs
>> from a generic dynamic array abstraction built to contain chars. That
>> being the case, I see no reason not to just do what everyone else does
>> when expanding dynamic arrays, and no reason why we shouldn't make
>> essentially the same time-space trade-off here as others do elsewhere.
>
> I agree with Peter on this one; not only is double-each-time the most
> widespread plan, but it is what we do in just about every other place
> in Postgres that needs a dynamically expansible buffer.  If you do it
> randomly differently here, readers of the code will be constantly
> stopping to wonder why it's different here and if that's a bug or not.

That could, of course, be addressed by adding a comment.

> (And from a performance standpoint, I'm not entirely convinced it's not
> a bug, anyway.  Worst-case behavior could be pretty bad.)

Instead of simply asserting that, could you respond to the specific
points raised in my analysis?  I think there's no way it can be bad.
I am happy to be proven wrong, but I like to understand why it is that
I am wrong before changing things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sortsupport for text
Next
From: Josh Berkus
Date:
Subject: Strange behavior with pg_locks and partitioning