Stephen Frost wrote: -- Start of PGP signed section. > Greetings, > > After watching a database import go abysmally slow on a pretty beefy > box with tons of RAM, I got annoyed and went to hunt down why in the > world PG wasn't using but a bit of memory. Turns out to be a well > known and long-standing issue: > > http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg101139.html > > Now, we could start by fixing guc.c to correctly have the max value > for these be MaxAllocSize/1024, for starters, then at least our users > would know when they set a higher value it's not going to be used. > That, in my mind, is a pretty clear bug fix. Of course, that doesn't > help us poor data-warehousing bastards with 64G+ machines. > > Sooo.. I don't know much about what the limit is or why it's there, > but based on the comments, I'm wondering if we could just move the > limit to a more 'sane' place than the-function-we-use-to-allocate. If > we need a hard limit due to TOAST, let's put it there, but I'm hopeful > we could work out a way to get rid of this limit in repalloc and that > we can let sorts and the like (uh, index creation) use what memory the > user has decided it should be able to.
Is this a TODO? Can we easily fix the tuplesort.c code? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers