Gokulakannan Somasundaram wrote:
It would be helpful to explain how this solves the lack of atomicity of
visibility data updates, which last time I checked was the killer
problem for this feature.
Hmmm... To put it more clearly, this problem occurs when there is a thick
index on a mutable function(marked as immutable). In order to avoid the
problem, i wrote the code that would not support functional indexes, it
would only support the normal ones. I think the main argument against Thick
Index was
- Visibility Map, which supports "Index only Scans" partially but by
occupying lesser space and doesn't have the functional index issue. Since
the main advantage of Thick Index was Index Only Scans, the community
preferred to wait for Visibility map
Heikki is working on the Visibility map and i think his observations might
help on Thick Index project.
The common ground between thick indexes and visibility map based
index-only-scans is the method to pass Datums from the index to the
executor, and all the executor and planner changes to take advantage of
that. In fact, even without thick indexes or visibility map, that would
provide some gain: we could use the data from the index to filter rows
before going to the heap to check visibility. For example if you have a
wide table with a text column, and there's an index on the text column,
it would be faster to do a full scan on the index for a predicate like
"textcol LIKE '%foobar%'", than a sequential scan of the heap, assuming
there's only few matches.
The thick index approach has a lot of limitations compared to using
visibility map: How to deal with functional indexes? How to deal with
datatypes with broken comparison functions? And it needs support from
each indexam separately, and is outright impossible in something like an
bitmap index. These have all been discussed before, but I believe the
executor and indexam API changes required are similar to that with the
visibility map. That part of the patch I'm very interested in, though I
haven't looked at it at all yet.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
