| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: 64-bit integers for GUC |
| Date: | 2006-07-31 01:24:47 |
| Message-ID: | 21471.1154309087@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> On Tuesday 25 July 2006 14:28, Josh Berkus wrote:
>> To be quite frank, current PostgreSQL can't effectively use more than
>> 256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
>> AFAIK.
> Josh, can you clarify this statement for me?
Perhaps I shouldn't put words in Josh' mouth, but I *think* what he
meant is that the tuplesort code does not get any faster once work_mem
exceeds a few hundred meg. I believe we've addressed that to some
extent in CVS HEAD, but it's a fair gripe against the existing release
branches.
I'm not aware that anyone has done any work to characterize performance
vs work_mem setting for any of the other uses of work_mem (such as hash
table sizes).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2006-07-31 02:37:51 | Re: Let psql process files with > 4,294,967,295 lines |
| Previous Message | Robert Treat | 2006-07-31 01:10:45 | Re: 64-bit integers for GUC |