On Fri, Jun 15, 2012 at 1:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jun 15, 2012 at 12:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> (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. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
