Re: Queries intermittently slow

Поиск
Список
Период
Сортировка
От Scott Rankin
Тема Re: Queries intermittently slow
Дата
Msg-id 6E19BC0B-89C0-4F0C-8565-1933DA4C22F6@motus.com
обсуждение исходный текст
Ответ на Re: Queries intermittently slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
>
>Hm, well, given that you are able to capture instances of the behavior
>in EXPLAIN ANALYZE, I'd suggest trying EXPLAIN (ANALYZE,BUFFERS).
>That will tell you the number of pages it found in shared buffers vs.
>having to read them.  Now, a "read" just means we had to ask the kernel,
>not necessarily that the page came all the way from disk; if it's in
>the kernel's disk cache that won't be very much slower than a shared-
>buffers hit.  Still, if the slowdowns are reliably seen only when a read
>occurred, I'd say that's good evidence.

Well, that was a good thought - but:

Nested Loop  (cost=0.00..4.20 rows=1 width=185) (actual time=567.113..567.113 rows=0 loops=1)
  Join Filter: (be.branding_id = b.branding_id)
  Rows Removed by Join Filter: 1
  Buffers: shared hit=4
  ->  Nested Loop  (cost=0.00..3.19 rows=1 width=189) (actual time=567.081..567.092 rows=1 loops=1)
        Join Filter: (s.setting_id = be.setting_id)
        Rows Removed by Join Filter: 41
        Buffers: shared hit=3
        ->  Seq Scan on branding_extension be  (cost=0.00..1.00 rows=1 width=8) (actual time=0.011..0.012 rows=1
loops=1)
              Buffers: shared hit=1
        ->  Seq Scan on setting s  (cost=0.00..2.04 rows=42 width=185) (actual time=567.041..567.049 rows=42 loops=1)
              Buffers: shared hit=2
  ->  Seq Scan on branding b  (cost=0.00..1.01 rows=1 width=4) (actual time=0.007..0.009 rows=1 loops=1)
        Filter: ((name)::text = 'crs'::text)
        Rows Removed by Filter: 1
        Buffers: shared hit=1
Total runtime: 567.185 ms


I ran it several times and there were no reads, just shared hits, even on slow executions.

It looks like it didn’t go out to the kernel for the data. I guess next steps would be to adjust the deadlock_timeout?
IfI’m reading the docs correctly, this doesn’t change how Postgres determines a deadlock, it just makes it check for
themsooner?
 

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Queries intermittently slow
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Queries intermittently slow