Re: Slow Bitmap Index Scan - Mailing list pgsql-performance
From | Scott Rankin |
---|---|
Subject | Re: Slow Bitmap Index Scan |
Date | |
Msg-id | D6617547-272E-4274-900B-BD1ABFE40930@motus.com Whole thread Raw |
In response to | Re: Slow Bitmap Index Scan (Justin Pryzby <pryzby@telsasoft.com>) |
List | pgsql-performance |
On 11/28/18, 2:18 PM, "Justin Pryzby" <pryzby@telsasoft.com> wrote: On Wed, Nov 28, 2018 at 07:08:53PM +0000, Scott Rankin wrote: > We recently moved our production database systems from a 9.4 running on a self-managed EC2 instance to 9.6.10 on Amazon’sAWS (same RAM, CPU). After the move, we’re finding that certain queries that we run against a GIN full-text indexhave some occasionally very slow executions and I’m struggling to figure out what to do about it. I would be verygrateful for any ideas! > > The setup we have is a 32-core, 244 GB RAM primary with a same-sized read replica. The queries are running off thereplica, but performance is roughly the same between the master and the replica. > > Here’s a query that’s performing badly: Can you compare or show the explain(analyze,buffers) for a fast query instance vs slow query instance ? Is it slower due to index access or heap? Due to cache misses ? If I reduce the number of search terms in , I get this: SELECT ls.location AS locationId FROM location_search ls WHERE ls.client = 83 AND search_field_tsvector @@ to_tsquery('9000:*'::text) AND ls.favorite = TRUE LIMIT 100 Limit (cost=13203.99..13627.40 rows=100 width=8) (actual time=66.568..66.759 rows=100 loops=1) Buffers: shared hit=1975 -> Bitmap Heap Scan on location_search ls (cost=13203.99..13923.79 rows=170 width=8) (actual time=66.568..66.729 rows=100loops=1) Recheck Cond: ((search_field_tsvector @@ to_tsquery('9000:*'::text)) AND (client = 83)) Filter: favorite Heap Blocks: exact=86 Buffers: shared hit=1975 -> BitmapAnd (cost=13203.99..13203.99 rows=170 width=0) (actual time=66.471..66.472 rows=0 loops=1) Buffers: shared hit=1889 -> Bitmap Index Scan on location_search_tsvector_idx (cost=0.00..2235.02 rows=11570 width=0) (actual time=20.603..20.604rows=29155 loops=1) Index Cond: (search_field_tsvector @@ to_tsquery('9000:*'::text)) Buffers: shared hit=546 -> Bitmap Index Scan on location_search_client_idx (cost=0.00..10968.63 rows=442676 width=0) (actual time=40.682..40.682rows=482415 loops=1) Index Cond: (client = 83) Buffers: shared hit=1343 Planning time: 0.181 ms Execution time: 66.806 ms I see almost no IO reads, and pg_stat_statements shows no cache misses. Also, you have big ram - have you tried disabling KSM or THP ? https://www.postgresql.org/message-id/20170718180152.GE17566%40telsasoft.com Since this is Amazon RDS, we don't have any control over or access to the underlying OS. I know that huge_page support ison for these instances. I would hope that Amazon's already done that... Justin This email message contains information that Motus, LLC considers confidential and/or proprietary, or may later designateas confidential and proprietary. It is intended only for use of the individual or entity named above and shouldnot be forwarded to any other persons or entities without the express consent of Motus, LLC, nor should it be usedfor any purpose other than in the course of any potential or actual business relationship with Motus, LLC. If the readerof this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient,you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.If you have received this communication in error, please notify sender immediately and destroy the original message. Internal Revenue Service regulations require that certain types of written advice include a disclaimer. To the extent thepreceding message contains advice relating to a Federal tax issue, unless expressly stated otherwise the advice is notintended or written to be used, and it cannot be used by the recipient or any other taxpayer, for the purpose of avoidingFederal tax penalties, and was not written to support the promotion or marketing of any transaction or matter discussedherein.
pgsql-performance by date: