-- create and populate a table with a GIN-indexable column
-- we pre-populate it to a large size; autovacuum kicks in when more than
-- a configured proportion of the table is newly inserted, and we want to
-- model the case where that doesn't happen often
drop table gtst;

set work_mem = '256MB';
set gin_fast_limit = '64kB';

create table gtst as
  select array[i,j,i*j] as a
    from generate_series(1,1000) i, generate_series(1,1000) j;

-- make the index (the fast update queue will be empty)
create index gtst_idx on gtst using gin (a);

insert into gtst select array[i,j,i*j] as a from generate_series(1,100) i, generate_series(1,100) j;
-- test performance; this query should be very fast:
explain analyze select * from gtst where a @> array[998001];

-- note that gin_fast_limit is set to the same size as work_mem
-- this mimics the current performance problem.
set gin_fast_limit = '256MB';

insert into gtst select array[i,j,i*j] as a from generate_series(1,100) i, generate_series(1,100) j;

-- observe the query is much slower
explain analyze select * from gtst where a @> array[998001];

-- test the index specific settings
set gin_fast_limit = '256MB';
alter index gtst_idx set (fastupdate=true);
alter index gtst_idx set (fast_cache_size=64);
-- alter index gtst_idx set (fast_cache_size=-1);

insert into gtst select array[i,j,i*j] as a from generate_series(1,100) i, generate_series(1,100) j;

-- observe the query is still fast, despite global settings
explain analyze select * from gtst where a @> array[998001];