Re: Fixing GIN for empty/null/full-scan cases

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> So some questions:

> * Is something seriously wrong with GiST index creation on integer[] columns?

> * Why does GIN performance appear to be no better than table scans on integer[] columns?

> * Why does it take 3-4x longer to create the GIN than the GiST index on tsvector? I thought that GIN was supposed to be faster to update

Hard to comment on any of this without a concrete example (including
data) to look at. Given the bugs we've recently found in the picksplit
algorithms for other contrib modules, I wouldn't be too surprised if the
sucky GiST performance traced to a similar bug in intarray. But I'm not
excited about devising my own test case.

One other point here is that GIN index build time is quite sensitive to
maintenance_work_mem --- what did you have that set to?

regards, tom lane