- Newest
- Most votes
- Most comments
Hello Lars,
Thank you for reaching us and I understand that you are running into a query performance slowness issue after using a PG GIN index for a full text search:
-> Bitmap Index Scan on search_records_btree_gin (cost=0.00..2184.00 rows=1 width=0) (actual time=4331.987..4331.987 rows=1 loops=1)
While query tuning is beyond the scope of this forum there are certainly a few things which I can recommend for additional deep dive on the issue:
a) I see you have used trigrams for the index but did you check on the bitmap scan performance without the trigrams to understand if that's adding any benefit
b) I will also go ahead and check if the index blocks are being cached by the DB:
[+] https://www.postgresguide.com/performance/cache/
[+] https://dba.stackexchange.com/questions/25513/postgresql-index-caching
c) Parameter track_io_timing might help show what component of that time is coming from IO and if it's indeed the IO fetch time from the disk. This parameter is off by default, as it will repeatedly query the operating system for the current time, which may cause significant overhead on some platforms:
[+] https://www.postgresql.org/docs/current/runtime-config-statistics.html
d) Is the table 'search_records' frequently written upon? If yes then I will also recommend you to check on the pending list size as it could lead to the slower performance:
[+] https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-GIN-PENDING-LIST-LIMIT
I sincerely hope that you will find these helpful.
Relevant content
- asked 7 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Sorry I was offline for a while. Thanks for all the pointers, I will look into this.