Re: One tuple per transaction

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Richard Huxton <dev(at)archonet(dot)com>, Tambet Matiisen <t(dot)matiisen(at)aprote(dot)ee>, pgsql-performance(at)postgresql(dot)org
Subject: Re: One tuple per transaction
Date: 2005-03-16 00:06:29
Message-ID: 20050316000629.GB17051@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Mar 15, 2005 at 06:51:19PM -0500, Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> > On a similar note I was just wondering if it would be possible to
> > mark any of these dead tuples as ready to be reused at transaction
> > commit time, since we know that they are dead to any and all other
> > transactions currently going on.
>
> I believe VACUUM already knows that xmin = xmax implies the tuple
> is dead to everyone.

Huh, that is too simplistic in a subtransactions' world, isn't it?

One way to solve this would be that a transaction that kills a tuple
checks whether it was created by itself (not necessarily the same Xid),
and somehow report it to the FSM right away.

That'd mean physically moving a lot of tuples in the page, so ISTM it's
too expensive an "optimization." Oh, and also delete the tuple from
indexes.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Sabino Mullane 2005-03-16 01:03:10 Re: Changing the random_page_cost default (was: cpu_tuple_cost)
Previous Message Tom Lane 2005-03-15 23:51:19 Re: One tuple per transaction