Re: the big picture for index-only scans

> > By your argument, we can say that no-one will create a index with a
> function
> > like random(), time(), date(), broken operators etc. Its hard to imagine
> a
> > index in which a a user will only want to insert and never select on it.
>
> The whole point of this optimization is to make index access cheaper,
> not more expensive. You seem convinced it's done the opposite, but
> you haven't offered much evidence (or any test results) to support
> that proposition.
>

I hope you are referring to thick indexes/covering indexes/indexes with
snapshot. Why do you think its done the opposite? In fact all the other
databases like Oracle, SQL-Server, Sybase implement the indexes with
snapshot (that's the only one they support). It makes the index tuple larger
by 8 bytes, but avoids the heap-fetch. I think, i ran a couple of
benchmarks, when i submitted the patch and showed the improvement. The
trade-off in that case was simple. Size of the index Vs avoiding a disk I/O.
User still has the choice of creating indexes without snapshot( it was
provided as an optional index).

>
> What we decided NOT to do is put xmin/xmax/cid into the index tuple,
> for precisely the reasons you mention. That would be catastrophic
> both for write operations to the table, and for the size of the index.
>
>
Why it would be catastrophic for write operations on table?? -please explain
me.
The trade-off in that case was simple. Size of the index Vs avoiding a disk
I/O. There was no catastrophic damage on the size of the index, as far as i
can see.

I made this point, because Heikki pointed out that since no-one is
complaining about some performance problem, and so we can assume that it
doesn't exist. But the thick index proposal was shot down on the context,
some one might create a index on a function like random(), time(). date() or
with broken operators, effectively meaning that you can insert into the
index and cannot select back. We are already doing unique checks and
referential integrity checks on that kind of indexes(which would all be
wrong), but still we should not be working in that area, to help user not
make that mistake of creating such indexes. So we should apply the same
principle for decision making here also.

Gokul.