Re: Vacuum: allow usage of more than 1GB of work mem
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
Claudio Freire <klaussfreire@gmail.com>, Greg Stark <stark@mit.edu>, Simon Riggs <simon@2ndquadrant.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Jim Nasby <Jim.Nasby@bluetreble.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-14T12:02:58Z
Lists: pgsql-hackers
On Wed, Sep 14, 2016 at 5:45 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> Another interesting bit about these small tables is that the largest used
> offset for these tables never went beyond 291 which is the value of
> MaxHeapTuplesPerPage. I don't know if there is something that prevents
> inserting more than MaxHeapTuplesPerPage offsets per heap page and I don't
> know at this point if this gives us upper limit for bits per page (may be it
> does).
>From PageAddItemExtended:
/* Reject placing items beyond heap boundary, if heap */
if ((flags & PAI_IS_HEAP) != 0 && offsetNumber > MaxHeapTuplesPerPage)
{
elog(WARNING, "can't put more than MaxHeapTuplesPerPage items
in a heap page");
return InvalidOffsetNumber;
}
Also see the comment where MaxHeapTuplesPerPage is defined:
* Note: with HOT, there could theoretically be more line pointers (not actual
* tuples) than this on a heap page. However we constrain the number of line
* pointers to this anyway, to avoid excessive line-pointer bloat and not
* require increases in the size of work arrays.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited