An idle thought
in [PgSql]
|
From: Jeff Davis on 18 Mar 2010 17:48 On Thu, 2010-03-18 at 17:17 -0400, Tom Lane 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? > > It doesn't. The only thing we currently rely on the VM for is deciding > whether a page needs vacuuming Oh, my mistake. I misremembered the discussion and I thought the seq scan optimization made it in. > In order to do things like not visiting a page during scans, we'll have > to solve the reliability issues. Yeah, and also for the index-only scans. 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: Jeff Davis on 18 Mar 2010 18:02 On Thu, 2010-03-18 at 14:48 -0700, Jeff Davis wrote: > On Thu, 2010-03-18 at 17:17 -0400, Tom Lane 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? > > > > It doesn't. The only thing we currently rely on the VM for is deciding > > whether a page needs vacuuming > > Oh, my mistake. I misremembered the discussion and I thought the seq > scan optimization made it in. > Hmm... >From heapgetpage() in heapam.c, CVS HEAD: /* * If the all-visible flag indicates that all tuples on the page are * visible to everyone, we can skip the per-tuple visibility tests. But I tested in gdb, and it calls HeapTupleSatisfiesMVCC, until I VACUUM a few times, and then it doesn't call it any more. So, apparently the seq scan optimization _is_ there. And that means it is correctness-critical. 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: Bruce Momjian on 22 Mar 2010 16:48 Jeff Davis wrote: > On Tue, 2010-03-16 at 15:29 +0000, Greg Stark wrote: > > I'm picturing storing a bit in the visibility map indicating that *no* > > records are visible in a given page. > > I've been thinking for a while that we could store the visibility > information in a structure separate from the heap -- sort of like the > visibility map, but per-tuple and authoritative rather than a per-page > hint. > > There are all kinds of challenges there, but it might be worth thinking > about. Visibility information is highly compressible, and requires > constant maintenance (updates, deletes, freezing, etc.). It also might > make it possible to move to 64-bit xids, if we wanted to. I don't think we want to move to 64-bit xids becasue we would still need to do vacuum freeze to trim the clog. In fact we do vacuum freeze much more frequently than required for 32-bit xids for this very reason. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- 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 22 Mar 2010 17:35 On Mon, 2010-03-22 at 16:48 -0400, Bruce Momjian wrote: > I don't think we want to move to 64-bit xids becasue we would still need > to do vacuum freeze to trim the clog. In fact we do vacuum freeze much > more frequently than required for 32-bit xids for this very reason. Good point. I think there are a lot of issues like this, which would make storing the visibility information separate from the heap a huge undertaking. Still worth thinking about, though. 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
First
|
Prev
|
Pages: 1 2 3 4 Prev: [HACKERS] An idle thought Next: parametrized NOTIFY - issue in plpgsql, maybe ToDo |