Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Also, we're using the same technique for TOASTed values. The cost can be
> > compared with "select * from mytable where toasted_value = something", no?
>
> No, because toast pointers point in the direction you need to traverse.
> AFAICS, this proposal involves scanning the whole index to find the
> matching entry, because the available pointers link from the wrong end,
> that is from the index to the table.
Ah, I see there are differences if we have secondary indexes.
I misunderstood that the toast case requires scanning the whole *table* to
find the matching entry and should be compared with the whole *index* scans,
but there is another story if we have secondary indexes.
We can have indexes on toasted values, and find the related tuples
directly with CTIDs, but scans on secondary indexes on PK-excluded
tables requires not only heap tuples but also primary key values.
The secondary index issue should be considered also with the original
IOT proposal also has the same issue. Using PK-values instead of CTIDs
might require many changes in index access methods and/or the executor.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
