Re: SELECT * FROM LIMIT 1; is really slow Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: SELECT * FROM LIMIT 1; is really slow
Дата
Msg-id 20040528200319.GA3111@dcc.uchile.cl
обсуждение исходный текст
Ответ на Re: SELECT * FROM LIMIT 1; is really slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, May 28, 2004 at 03:48:11PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > 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.  We only need to store the "borders" though.  Not even that: only
> > the start, because the end is what is current at AbortSubTransaction()
> > time.
> 
> Nope.  Think about sub-subtransactions.

They are all aborted if the parent is, so

BEGIN;BEGIN;                -- cid = 1    BEGIN;            -- cid = 2        INSERT INTO foo VALUES (1)    -- cid=3
COMMIT;ROLLBACK;       -- aborts from Cid 1 to Cid 3-- here we can't see the tuple because Xmin == my-xid-- and Cmin=1
isaborted
 
COMMIT;

I assume this is how you think it works, isn't it?  Because if not I am
in serious trouble.  But if it is, then CommandIds from 1 ("start Cid")
and 3 ("current Cid") are aborted.  And this can be kept in the master
bitmap --- in fact, I didn't think about another one.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Un poeta es un mundo encerrado en un hombre" (Victor Hugo)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: On query rewrite
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SELECT * FROM LIMIT 1; is really slow