I am glad you have summarized this. The details of exactly what was being proposed was too complex for me to understand before.
--------------------------------------------------------------------------- Tom Lane wrote: > I just finished looking through the various threads about index AM > changes that Bruce has been holding onto in the commit-fest queue. > There seem to be the following issues: > > * Proposed change to have amgetmulti return its results by ORing bits > into a caller-supplied TIDBitmap, rather than the current interface > involving an intermediate TID array. The TID-array design was intended > to be agnostic about what would happen on either side of the API, but it > seems that it's really just equally inconvenient for everybody :-(. > > Although the original motivation for this was to open a door for bitmap > indexes, it seems to me it's worth doing whether or not bitmap indexes > ever happen. It's logically simpler (only one amgetmulti call per scan) > and should save at least a few cycles. I recommend we just go ahead > with this. > > * Proposed change to let both amgetnext and amgetmulti mark returned > tuples as "candidate matches", that is in need of rechecking of quals > against the real heap tuple. I had originally objected to this on > the grounds that it would require setup work that doesn't happen now, > but looking at the code I see that's wrong --- the setup work *does* > happen anyway, see indexqualorig. nodeIndexscan.c comments "The > indexqualorig expression is always initialized even though it will only > be used in some uncommon cases --- would be nice to improve that". > So this complaint is probably a red herring. I'm still a bit concerned > by the fact that the patch only tracks this on a page basis in the > amgetmulti case: if any of the tuples on a page are in-doubt then > everything on the page will have to be rechecked. Is that good enough? > > A bigger issue is whether this is worth applying when nobody seems to be > working on either of the main uses for it (bitmap indexes and GIT > indexes). There seemed to be some possible marginal use for it in GIST > indexes, but I'm not convinced that's a sufficient reason to complicate > the APIs. > > * Proposed change to let amgetnext mark returned tuples as not > necessarily in order, requiring somebody downstream to sort them again. > I was pretty desperately unhappy with that because it required injection > of sorting knowledge into code that really shouldn't have anything to do > with it --- not least because not all indexscans even have a defined > ordering. Given that it is only needed for one particular possible > implementation of GIT, and Heikki was leaning away from that > implementation anyway at last report, I vote against considering this > any further. > > * Proposed changes to refactor the TIDBitmap support to include a > concept of a "stream bitmap" being read from disk. (Not strictly an > index AM change, but closely related.) While this is clean and nice on > its own, it doesn't seem to have any use unless bitmap indexes happen. > If we leave the code sit it'll probably acquire bit rot, but I'm > disinclined to add a bunch of unused code, too. Thoughts? > > * Proposed changes to allow amgetnext to return the actual index keys, > allowing certain types of "unindexable" quals to be checked without > having to fetch the heap entry. For example a LIKE condition could be > fully checked against the index entry. Since certain types of indexes > (GIN now, possibly hash in future) are incapable of doing this, there'd > need to be a way of marking index AMs (or perhaps individual indexes) as > able or not able to return their keys, so that the planner could know > whether quals could be pushed into the indexscan. > > We don't have any actual submitted patch for this, but AFAIR everyone > agrees it's a good idea. > > * Bitmap indexes themselves. As far as I can tell, this development > effort has stalled because of intractable problems with VACUUM. > Can anyone provide a status update on that? > > * GIT (Grouped Index Tuple) indexes, which achieve index space savings > in btrees by having a single index tuple represent multiple heap tuples > (on a single heap page) containing a range of key values. I am not sure > what the development status is --- Heikki had submitted a completed > patch but there seemed to be agreement on making changes, and that's not > been done AFAIK. The really serious problem I've got with it is that > it'd foreclose the possibility of returning actual index keys from btree > indexes, thus basically killing the usefulness of that idea. I'm not > convinced it would offer enough gain to be worth paying that price. > Another issue is that we'd need to check how much of the use-case for > GIT has been taken over by HOT. > > * "Thick" indexes containing copies of tuple visibility info. As far > as I'm concerned, this patch isn't going anywhere :-(. It's got the > same showstopper problem as retail vacuum and some of the earlier forms > of the HOT patch: it assumes that during tuple update or delete, it > can re-find the tuple's index entries by re-computing the indexed > expressions. That's just not reliable enough. > > Is that a reasonable summary of where we are? > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
