An idle thought
in [PgSql]
|
From: Tom Lane on 18 Mar 2010 16:50 Jeff Davis <pgsql(a)j-davis.com> writes: > On Fri, 2010-03-19 at 01:59 +0530, Gokulakannan Somasundaram wrote: >> I believe it is very difficult to make visibility map update friendly >> without compromising durability. But such a functionality is very >> much wanted in PG still. > Surely the VM is already update-friendly. If you update a tuple in a > page with the visibility bit set, the bit must be unset or you will get > wrong results. The VM is (a) not compressed and (b) not correctness-critical. Wrong bit values don't do any serious damage. regards, tom lane -- 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: Jeff Davis on 18 Mar 2010 17:07 On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote: > The VM is (a) not compressed and (b) not correctness-critical. > Wrong bit values don't do any serious damage. The VM cause wrong results if a bit is set that's not supposed to be -- right? Am I missing something? How does a seq scan skip visibility checks and still produce right results, if it doesn't rely on the bit? The visibility map would obviously not be very useful if visibility information was randomly distributed among tuples. Whether that qualifies as "compression" or not was not my primary point. The point is that it may be possible to use some structure that is significantly smaller than holding xmin/xmax for every tuple in the heap, and at the same time may be acceptably fast to update. Regards, Jeff Davis -- 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: Alex Hunsaker on 18 Mar 2010 17:11 On Thu, Mar 18, 2010 at 15:07, Jeff Davis <pgsql(a)j-davis.com> wrote: > On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote: >> The VM is (a) not compressed and (b) not correctness-critical. >> Wrong bit values don't do any serious damage. > > The VM cause wrong results if a bit is set that's not supposed to be -- > right? Am I missing something? How does a seq scan skip visibility > checks and still produce right results, if it doesn't rely on the bit? Isn't it only really used for VACUUM at this point? -- 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: Tom Lane on 18 Mar 2010 17:17 Jeff Davis <pgsql(a)j-davis.com> writes: > On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote: >> The VM is (a) not compressed and (b) not correctness-critical. >> Wrong bit values don't do any serious damage. > The VM cause wrong results if a bit is set that's not supposed to be -- > right? Am I missing something? How does a seq scan skip visibility > checks and still produce right results, if it doesn't rely on the bit? It doesn't. The only thing we currently rely on the VM for is deciding whether a page needs vacuuming --- and even that we don't trust it for when doing anti-wraparound vacuuming. The worst-case consequence of a wrong bit is failure to free some dead tuples until the vacuum freeze limit expires. In order to do things like not visiting a page during scans, we'll have to solve the reliability issues. regards, tom lane -- 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: Greg Stark on 18 Mar 2010 17:28 On Thu, Mar 18, 2010 at 9:07 PM, Jeff Davis <pgsql(a)j-davis.com> wrote: > The VM cause wrong results if a bit is set that's not supposed to be -- > right? Am I missing something? How does a seq scan skip visibility > checks and still produce right results, if it doesn't rely on the bit? > There's also a PD_ALL_VISIBLE flag on the page header. We wal log when we clear that bit so we can trust if it's set then all the tuples really are visible. I forget whether we can trust it if it's *not* set but there's not much point -- all tuples could become visible spontaneously even the page is sitting on disk. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] An idle thought Next: parametrized NOTIFY - issue in plpgsql, maybe ToDo |