I'm spoiled by using pg_stat_statements to find the hotspot queries which
could use some attention.
But with some recent work, all of the hotspots are of the form "FETCH 1000
FROM c3". The vast majority of the queries return less than 1000 rows, so
only one fetch is issued per execution.
Is ther
Adam Brusselback writes:
> Is there any easy way I can know if an index is usable or not? Are there
> any catalog views or anything I could check that in?
IIRC, you can look at pg_index.indcheckxmin --- if that's set, then
the index had broken HOT chains during creation and may not be usable
righ
>
> Does the "multiple steps" part involve UPDATEs on pre-existing rows?
> Do the updates change the column(s) used in the gin index?
>
Yes they do, however the updates happen prior to the index creation.
I just tried, and that looks like the solution. I really appreciate your
help on this.
Is
Adam Brusselback writes:
> I have a function which builds two temp tables, fills each with data (in
> multiple steps), creates a gin index on one of the tables, analyzes each
> table, then runs a query joining the two.
> My issue is, I am getting inconsistent results for if the query will use
> th
Hey all, first off, i'm running: PostgreSQL 9.6.3 on x86_64-pc-linux-gnu,
compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit
At the high level, I am having an issue with a query not using an index,
and in a very hard to reproduce way.
I have a function which builds two temp tables, fills each with d
