Prev: [HACKERS] An idle thought
Next: parametrized NOTIFY - issue in plpgsql, maybe ToDo
From: Simon Riggs on 17 Mar 2010 20:03
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 been thinking that for a while, but I've yet to see
a fully costed assessment of whether its worth doing. It might be.

It seems easier to focus on outcomes rather than specifics, then order
the possible solutions to those outcomes in cost-benefit sequence.

--
Simon Riggs www.2ndQuadrant.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: Gokulakannan Somasundaram on 18 Mar 2010 04:59
On Thu, Mar 18, 2010 at 2:50 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> Jeff Davis <pgsql(a)j-davis.com> 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 you want it to be cheaply updatable (or even cheaply readable),
> compression is not what you're going to do.
>
> regards, tom lane
>
> +1..
From: Jeff Davis on 18 Mar 2010 14:21
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
>
>
>
> +1..

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.

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: Gokulakannan Somasundaram on 18 Mar 2010 16:29
> 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 a functionality is very much
wanted in PG still.
From: Jeff Davis on 18 Mar 2010 16:34
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.
>
>
> 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.

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  |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] An idle thought
Next: parametrized NOTIFY - issue in plpgsql, maybe ToDo