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
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) |