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)
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 |