Idea for getting rid of VACUUM FREEZE on cold pages
in [PgSql]
|
Prev: [HACKERS] beta testing - planner bug - ERROR: XX000: failed to build any 2-way joins
Next: [HACKERS] beta testing - pg_upgrade bug fix - double free
From: Heikki Linnakangas on 26 May 2010 01:04 On 25/05/10 23:56, Josh Berkus wrote: > Do we get a bit in the visibility map for a page which has aborted > transaction rows on it? If there's a tuple with an aborted xmin on a page, the bit in the visibility map is not set. A tuple with aborted xmax doesn't matter. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 26 May 2010 14:35 On 5/25/10 10:04 PM, Heikki Linnakangas wrote: > On 25/05/10 23:56, Josh Berkus wrote: >> Do we get a bit in the visibility map for a page which has aborted >> transaction rows on it? > > If there's a tuple with an aborted xmin on a page, the bit in the > visibility map is not set. A tuple with aborted xmax doesn't matter. Then it seems like pages in the visibility map, at least, would not need to be vacuumed or frozen. Do pages persist in the visibility map indefinitely? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 26 May 2010 14:44 On 26/05/10 21:35, Josh Berkus wrote: > On 5/25/10 10:04 PM, Heikki Linnakangas wrote: >> On 25/05/10 23:56, Josh Berkus wrote: >>> Do we get a bit in the visibility map for a page which has aborted >>> transaction rows on it? >> >> If there's a tuple with an aborted xmin on a page, the bit in the >> visibility map is not set. A tuple with aborted xmax doesn't matter. > > Then it seems like pages in the visibility map, at least, would not need > to be vacuumed or frozen. Do pages persist in the visibility map > indefinitely? In theory, until any tuple on the page is inserted/updated/deleted again. However, we've been operating on the assumption that it's always safe to clear any bit in the visibility map, without affecting correctness. I would not like to give up that assumption, it makes life easier. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 26 May 2010 14:46 > In theory, until any tuple on the page is inserted/updated/deleted > again. However, we've been operating on the assumption that it's always > safe to clear any bit in the visibility map, without affecting > correctness. I would not like to give up that assumption, it makes life > easier. It wouldn't affect correctness, it would just force that page to be vacuumed-and-frozen. I think I can make this work, let me just hammer it out. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 26 May 2010 15:13
On Wed, May 26, 2010 at 2:44 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > On 26/05/10 21:35, Josh Berkus wrote: >> On 5/25/10 10:04 PM, Heikki Linnakangas wrote: >>> On 25/05/10 23:56, Josh Berkus wrote: >>>> Do we get a bit in the visibility map for a page which has aborted >>>> transaction rows on it? >>> >>> If there's a tuple with an aborted xmin on a page, the bit in the >>> visibility map is not set. A tuple with aborted xmax doesn't matter. >> >> Then it seems like pages in the visibility map, at least, would not need >> to be vacuumed or frozen. Do pages persist in the visibility map >> indefinitely? > > In theory, until any tuple on the page is inserted/updated/deleted again. > However, we've been operating on the assumption that it's always safe to > clear any bit in the visibility map, without affecting correctness. I would > not like to give up that assumption, it makes life easier. What if we drove it off of the PD_ALL_VISIBLE bit on the page itself, rather than the visibility map bit? It would be safe to clear the visibility map bit without touching the page, but if you clear the PD_ALL_VISIBLE bit on the page itself then you set all the hint bits and freeze all the tuples. In the case where the visibility map bit gets cleared but the page-level bit is still set, a future vacuum can notice and reset the visibility map bit. But whenever the visibility map bit is set, you know that the page-level bit MUST be set, so you needn't vacuum those pages, even for anti-wraparound: you know they'll be frozen when and if they ever get written again. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |