On Sat, Mar 07, 2015 at 12:46:42AM -0500, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Thu, Mar 05, 2015 at 03:28:12PM -0600, Jim Nasby wrote: > >> I was thinking the simpler route of just repalloc'ing... the memcpy would > >> suck, but much less so than the extra index pass. 64M gets us 11M tuples, > >> which probably isn't very common. > > > +1. Start far below 64 MiB; grow geometrically using repalloc_huge(); cap > > growth at vac_work_mem. > > +1 for repalloc'ing at need, but I'm not sure about the "start far below > 64 MiB" part. 64MB is a pretty small amount on nearly any machine these > days (and for anybody who thinks it isn't, that's why maintenance_work_mem > is a tunable).
True; nothing would explode, especially since the allocation would be strictly smaller than it is today. However, I can't think of a place in PostgreSQL where a growable allocation begins so aggressively, nor a reason to break new ground in that respect. For comparison, tuplestore/tuplesort start memtupsize at 1 KiB. (One could make a separate case for that practice being wrong.) > A different line of thought is that it would seem to make sense to have > the initial allocation vary depending on the relation size. For instance, > you could assume there might be 10 dead tuples per page, and hence try to > alloc that much if it fits in vac_work_mem. Sounds better than a fixed 64 MiB start, though I'm not sure it's better than a fixed 256 KiB start. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers