Gavin Sherry <[EMAIL PROTECTED]> writes: > Is anyone else looking at this patch?
It's on my list of things to look at, but so are a lot of other patches ;-) A couple of comments after a *very* fast scan through the patch: * The xlog routines need help; they seem to not be updated for recent changes in the API for xlog recovery code. * The hacks on vacuum.c (where it tests the AM name) are utterly unacceptable. If you need the main code to do something special for a particular index AM, define a bool flag column for it in pg_am. * The interface to the existing executor bitmap scan code is mighty messy --- seems like there's a lot of almost duplicate code, a lot of rather invasive hacking, etc. This needs to be rethought and refactored. * Why in the world is it introducing duplicate copies of a lot of btree comparison functions? Use the ones that are there. * The patch itself is a mess: it introduces .orig and .rej files, changes around $PostgreSQL$ lines, etc. However, the main problem I've got with this is that a new index AM is a pretty large burden, and no one's made the slightest effort to sell pghackers on taking this on. What's the use-case, what's the performance like, where is it really an improvement over what we've got? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match