Re: Multi-Entry Indexing for GiST & SP-GiST

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