Skip to main content
2 votes
Accepted

PostgreSQL uses slow Index Scan instead of Bitmap Heap + Index scan with ORDER BY and specific LIMIT

PostgreSQL has two choices to process the query: it can use an index for the WHERE clause, then sort and return the first few results (that's your fast plan) it can use an index for the ORDER BY ...
Laurenz Albe's user avatar
  • 53.9k
1 vote
Accepted

What impact has uniqueness constraint jsonb on postgres db performance

I'll ignore the "why" question. Look at the pgsql-hackers archives; it is all open source. You need a B-tree index for a unique constraint. Putting the index directly on the JSON column is ...
Laurenz Albe's user avatar
  • 53.9k
1 vote

PostgreSQL uses slow Index Scan instead of Bitmap Heap + Index scan with ORDER BY and specific LIMIT

Fastest solution for skewed data would be partial index. In your case an index like below will be fast as well super compact. You can tweak and test the index by changing index column or filtering ...
mediocre's user avatar
  • 168
1 vote

Alter timestamptz column to timestamp, without re-writing the table

You already saw my related answer addressing the reverse conversion timestamp → timestamptz without table rewrite: ALTER timestamp column to timestamptz, without "converting" data? Well, ...
Erwin Brandstetter's user avatar
1 vote

Postgres planning time is very high

1.6M dead tuples in pg_statistic is way beyond normal. If you are at liberty to do so: VACUUM FULL pg_catalog.pg_statistic; Else, at least plain VACUUM. I wonder how you got there. Looks like very ...
Erwin Brandstetter's user avatar

Only top scored, non community-wiki answers of a minimum length are eligible