| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
| 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 04:44:30 |
| Message-ID: | 2284.1110948270@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Tue, Mar 15, 2005 at 06:51:19PM -0500, Tom Lane wrote:
>> 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?
Well, it's still correct as a fast-path check. There are extensions
you could imagine making ... but offhand I agree that it's not worth
the trouble. Maybe in a few years when everyone and his sister is
using subtransactions constantly, we'll feel a need to optimize these
cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-03-16 07:23:47 | Re: cpu_tuple_cost |
| Previous Message | Qingqing Zhou | 2005-03-16 01:44:18 | Re: interesting benchmarks PG/Firebird Linux/Windows fsync/nofsync |