Hi Matthias, > I'm not trying to say that you need to fork the AM; that's not my > point. What I am trying to say is that by adding multi-entry, a lot of > edge cases need to be considered and added to the GIST AM definition > itself. A separate IndexAmRoutine which defines the multi-entry > variant would make more sense to me, even if they were to share most > of their internals and physical format definitions.
I agree with you that there are some differences in the way multi-entry indices work that would suggest that 2 different AMs makes more sense. I have tried such an implementation, but while doing so I hit one big problem. For now, multicolumn indices are allowed, with the condition that only one of the key columns can be multi-entry (the others get their value duplicated for every entry). This works currently because the single-entry columns use the existing GiST opclasses. If we create a new AM (e.g. MGiST), we would either have to restrict the index to a single column, or need to duplicate all GiST opclasses as new MGiST single-entry opclasses. What are your thoughts on this? Do you see a more restricted MGiST being better, or would this complication make you favor the current design over a new AM? > A nit about memory: If you swap the order of GISTTIDHashEntry's hash > and status fields, the size of the struct drops to 12B from its > current 16B; it's probably worth benchmarking to see if the lack of > power-of-two alignment is worth the increased memory efficiency. Indeed, good catch, I'll verify this for the next version. I haven't made progress on the hash table memory bounds for large result sets yet, so suggestions are more than welcome. Best, Maxime
