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 the
Jeff Davis wrote:
> On Tue, 2010-03-16 at 15:29 +, 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 f
> 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.
>
>
>
I was referring in the context of index only scans to skip visibility
checks. I doubt, whether the visibility map feature to skip v
Jeff Davis writes:
> 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.
The page header bit is critical. Not the VM.
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 resul
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
On Thu, Mar 18, 2010 at 9:07 PM, Jeff Davis 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_VISIBL
Jeff Davis 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
On Thu, Mar 18, 2010 at 15:07, Jeff Davis 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 --
> rig
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 visibi
Jeff Davis 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-fri
On Fri, 2010-03-19 at 01:59 +0530, Gokulakannan Somasundaram wrote:
>
> The visibility map itself is already an example of
> compression. If
> visibility information were randomly distributed among tuples,
> the
> visibility map would be nearly useless.
>
> The visibility map itself is already an example of compression. If
> visibility information were randomly distributed among tuples, the
> visibility map would be nearly useless.
>
>
> I believe it is very difficult to make visibility map update friendly
without compromising durability. But such
On Thu, 2010-03-18 at 14:29 +0530, Gokulakannan Somasundaram wrote:
> If you want it to be cheaply updatable (or even cheaply
> readable),
> compression is not what you're going to do.
>
>regards, tom lane
>
>
>
si...@2ndquadrant.com (Simon Riggs) writes:
> On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote:
>
>> big batch delete
>
> Is one of the reasons for partitioning, allowing the use of truncate.
Sure, but it would be even nicer if DELETE could be thus made cheaper
without needing to interfere with
>
>
> I didn't mean that we'd want to compress it to the absolute minimum
> size. I had envisioned that it would be a simple scheme designed only to
> eliminate long runs of identical visibility information (perhaps only
> the frozen and always visible regions would be compressed).
>
> The extra le
>
> Secondly there's the whole retail vacuum problem -- any
> index entries referring to this page would be left dangling unless
> there's some kind of retail vacuum or perhaps a page version number.
>
>
The issue, we can divide into two
a)volatile functions
b)broken datatypes
For a) I think vola
On Thu, Mar 18, 2010 at 2:50 AM, Tom Lane wrote:
> Jeff Davis writes:
> > 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
> >
On Wed, 2010-03-17 at 14:09 -0700, Jeff Davis wrote:
> 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.
A lot of people have be
On Wed, 2010-03-17 at 17:20 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > 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
> >
Jeff Davis writes:
> 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.
If
On Tue, 2010-03-16 at 15:29 +, 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 t
On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote:
> big batch delete
Is one of the reasons for partitioning, allowing the use of truncate.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Greg Stark writes:
> However then I started thinking about this case and wondered if it
> wouldn't be possible to optimize. One of the suggested optimizations
> was to look at using TRUNCATE. But I wonder why it's necessary to use
> a dedicated command. Shouldn't it be possible for the system to n
A few days ago there was a thread on one of our lists where someone
was suprised it took as much i/o to delete data as it took to insert
it in the first place. At first this does seem surprising but the fact
that Postgres stores its transaction information inline with the data
and does all i/o in b
25 matches
Mail list logo
