>
> It's a fairly corner case feature, only for the case where you're
> looking for the existance of an index key but don't want any other
> data. I don't personally have any queries that could use such a
> construct, though maybe I'm missing the point.
I understand the difficulty of implementat
Martijn van Oosterhout writes:
> It's a fairly corner case feature, only for the case where you're
> looking for the existance of an index key but don't want any other
> data. I don't personally have any queries that could use such a
> construct, though maybe I'm missing the point.
You don't ha
Martijn van Oosterhout writes:
> If someone wants to step up and write the code, well... Bit hard, it
> means that everytime a row is updated the index needs to be updated
> too, gotta get all the corner cases, locking, etc.
Even if someone did step up and write the code, the patch would probably
On Sun, Mar 06, 2005 at 11:54:52PM +0200, Ioannis Theoharis wrote:
> > Visibility information. An index contains references to all rows in all
> > transactions. You need to go back to the table to work out if the row
> > is visible in your transaction.
> >
> > Hope this helpsm
>
> Yes at all.
> Yo
>
> Visibility information. An index contains references to all rows in all
> transactions. You need to go back to the table to work out if the row
> is visible in your transaction.
>
> Hope this helpsm
Yes at all.
You have a lot of work for future postgresql' versions :-))
---
> >
> > As far as i can see, postgresql select a simple "INDEX SCAN using index"
> > on table.
>
> That's because the index does not hold all the information. So INDEX
> ONLY is impossible.
>
Thank you for your quick answer, but there is something a don't
understand:
the index holds all attribu
On Sun, Mar 06, 2005 at 11:39:05PM +0200, Ioannis Theoharis wrote:
> > > As far as i can see, postgresql select a simple "INDEX SCAN using index"
> > > on table.
> >
> > That's because the index does not hold all the information. So INDEX
> > ONLY is impossible.
> >
>
> Thank you for your quick an
On Sun, Mar 06, 2005 at 10:38:22PM +0200, Ioannis Theoharis wrote:
> in case that one has a table R(att0 int4, att1 int4), an index on att1
> and a query selecting only att1 whith a range condition over att1, then
> the optimal access path for a rdbms would be "INDEX ONLY SCAN", which means
> scan
Hi,
in case that one has a table R(att0 int4, att1 int4), an index on att1
and a query selecting only att1 whith a range condition over att1, then
the optimal access path for a rdbms would be "INDEX ONLY SCAN", which means
scan only the index, and not the relation (all the needed information
exi
