Re: Reduce pinning in btree indexes

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduce pinning in btree indexes
Date: 2015-03-16 12:48:34
Message-ID: 717321648.246214.1426510114028.JavaMail.yahoo@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> On 13 March 2015 at 15:41, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
>
>> The feedback was generally fairly positive except for the fact that
>> snapshot "age" (for purposes of being too old) was measured in
>> transaction IDs assigned. There seemed to be a pretty universal
>> feeling that this needed to be changed to a time-based setting.
>
> -1 for a time based setting.
>
> After years of consideration, bloat is now controllable by altering
> the size of the undo tablespace.
>
> I think PostgreSQL needs something size-based also. It would need some
> estimation to get it to work like that, true, but it is actually the
> size of the bloat we care about, not the time. So we should be
> thinking in terms of limits that we actually care about.

Are you thinking, then, that WAL volume generated (as determined by
LSN) would be the appropriate unit of measure for this? (We would
still need to map that back to transaction IDs for vacuuming, of
course.) If we did that we could allow the "size" units of
measure, like '5GB' and similar. Or are you thinking of something
else?

Given that there seems to be disagreement on what is the more
useful metric, do we want to consider allowing more than one? If
so, would it be when *all* conditions are met or when *any*
conditions are met?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-03-16 12:51:16 Re: Join push-down support for foreign tables
Previous Message Robert Haas 2015-03-16 12:39:16 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)