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

On Tue, Jun 01, 2004 at 02:37:37PM +0200, Manfred Koizar wrote:
> On Fri, 28 May 2004 21:59:53 -0400, Alvaro Herrera
> <alvherre(at)dcc(dot)uchile(dot)cl> wrote:
> >So the assumption was that when we see that this has
> >happenned, the Cmin is no longer important (== every future command can
> >already see the tuple)
>
> If it was that simple, we wouldn't have had to invent the CMIN_IS_CMAX
> flag. This has been discussed two years ago. Did you follow the link I
> posted last week? "Every future command" is not enough. You have to
> consider the current command and even commands started before this.

Yes, I did follow it (you mean XMAX_IS_XMIN, right? I suppose no tuple
can really have Cmin == Cmax). I'm not claiming I understood it fully
though. But as you see, since the assumption is not valid we have to
drop the idea and put back the Xmax as a field on its own on
HeapTupleHeader (which is what I had done before Bruce persuaded me not
to). I don't really like this idea but I don't see other way out.

A couple of days ago I was going to propose putting Xmax as a separate
field only as needed, in a way similar to the way Oid is handled ---
thus we would enlarge the tuple if and only if the creating transaction
deletes it. This would be nice because one would expect that there are
not that many tuples created and deleted by the same transaction, so
we'd localize the inefficiency of storing both fields (Cmin and Xmax)
only on tuples that need it. While I was writing the proposal I
realised that it'd mean enlarging tuples that are already on disk, and
there's no way we can do that.

If you have other ideas I'm all ears. I'm the last one to want that
nested xacts make everything else work slower.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)