Re: Slow Bitmap Index Scan

Поиск
Список
Период
Сортировка
От Scott Rankin
Тема Re: Slow Bitmap Index Scan
Дата
Msg-id EE225117-33A4-45E7-9D41-680D591AC5C9@motus.com
обсуждение исходный текст
Ответ на Re: Slow Bitmap Index Scan  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Slow Bitmap Index Scan
Список pgsql-performance
Upon further analysis, this is - unsurprisingly - taking place when we have multiple prefixed search terms in a
ts_querygoing against a tsvector index.
 

We have roughly 30 million rows in the table, and the search column is basically a concatenation of a location's name
(think"Walmart #123456") and its street address.
 

We use these searches mostly for autocompleting of a location search.  So the search for that record above might be
"Walmart123", which we change to be to_tsquery('walmart:* &123:*').  We prefix both terms to correct for misspellings
orlazy typing.
 

Is it unrealistic to think that we could have sub-1000ms searches against that size of a table?

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 ?

    Also, you have big ram - have you tried disabling KSM or THP ?
    https://www.postgresql.org/message-id/20170718180152.GE17566%40telsasoft.com

    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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
Следующее
От: Alan Hodgson
Дата:
Сообщение: Re: Slow Bitmap Index Scan