Re: sortsupport for text - Mailing list pgsql-hackers

From Tom Lane
Subject Re: sortsupport for text
Date
Msg-id 4935.1339798232@sss.pgh.pa.us
Whole thread Raw
In response to Re: sortsupport for text  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: sortsupport for text
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jun 15, 2012 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Maybe I missed something, but as far as I saw your argument was not that
>> the performance wasn't bad but that the rest of the sort code would
>> dominate the runtime anyway. �I grant that entirely, but that doesn't
>> mean that it's good for this piece of it to possibly have bad behavior.

> That, plus the fact that not wasting memory in code paths where memory
> is at a premium seems important to me.  I'm shocked that either of you
> think it's OK to overallocate by as much as 2X in a code path that's
> only going to be used when we're going through fantastic gyrations to
> make memory usage fit inside work_mem.  The over-allocation by itself
> could easily exceed work_mem.

I would be concerned about this if it were per-sort-tuple wastage, but
what I understood to be happening was that this was a single instance of
an expansible buffer (per sort, perhaps, but still just one buffer).
And, as you keep pointing out when it suits your argument, it's
relatively uncommon to be sorting enormous values anyway.  So no, I am
not particularly worried about that.  If you are, there are more
important places to be concerned about allocation pad wastage, starting
with palloc itself.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Resource Owner reassign Locks
Next
From: Tom Lane
Date:
Subject: Re: libpq compression