Skip site navigation (1) Skip section navigation (2)

Re: SELECT * FROM <table> LIMIT 1; is really slow

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>,David Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Date: 2004-05-28 19:36:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, May 28, 2004 at 03:19:29PM -0400, Tom Lane wrote:

> We'd still need a plain CommandCounterIncrement facility, which means
> that actually a subtransaction would have to be a group of CIDs not just
> one.

Right, this is why I suggested runlength (the group is contiguous).

> So there'd also need to be a data structure showing the CIDs
> associated with each open subtransaction --- this is what you'd
> consult to go and set the "aborted" bits if the subxact rolls back.

Right.  We only need to store the "borders" though.  Not even that: only
the start, because the end is what is current at AbortSubTransaction()

I'll try this.

Alvaro Herrera (<alvherre[a]>)
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-05-28 19:48:11
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Previous:From: Andrew DunstanDate: 2004-05-28 19:31:14
Subject: Re: patch for different join result order on regression test for

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group