I'm okay with any of the proposed designs or with dropping the idea. Closing
the loop on a few facts:
On Sat, Mar 07, 2015 at 04:34:41PM -0600, Jim Nasby wrote:
> If we go that route, does it still make sense to explicitly use
> repalloc_huge? It will just cut over to that at some point (128M?) anyway,
> and if you're vacuuming a small relation presumably it's not worth messing
> with.
repalloc_huge() differs from repalloc() only in the size ceiling beyond which
they raise errors. repalloc() raises errors for requests larger than ~1 GiB,
while repalloc_huge() is practically unconstrained on 64-bit and permits up to
~2 GiB on 32-bit.
On Mon, Mar 09, 2015 at 05:12:22PM -0500, Jim Nasby wrote:
> Speaking of which... people have referenced allowing > 1GB of dead tuples,
> which means allowing maintenance_work_mem > MAX_KILOBYTES. The comment for
> that says:
>
> /* upper limit for GUC variables measured in kilobytes of memory */
> /* note that various places assume the byte size fits in a "long" variable
> */
>
> So I'm not sure how well that will work. I think that needs to be a separate
> patch.
On LP64 platforms, MAX_KILOBYTES already covers maintenance_work_mem values up
to ~2 TiB. Raising the limit on ILP32 platforms is not worth the trouble.
Raising the limit on LLP64 platforms is a valid but separate project.
nm