From: | "Pweaver (Paul Weaver)" <pweaver(at)panjiva(dot)com> |
---|---|
To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, Michael Vezza <michael(at)panjiva(dot)com> |
Subject: | Re: Postgres Query Plan Live Lock |
Date: | 2014-02-05 19:36:47 |
Message-ID: | CAFTGa=nAncPgmy2kr3i+-9LW-s-Er4yfeiUrZ2ooEfsDwpO9HQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Feb 4, 2014 at 9:03 PM, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com
> wrote:
> On Mon, Feb 3, 2014 at 1:35 PM, Pweaver (Paul Weaver)
> <pweaver(at)panjiva(dot)com> wrote:
> > We have been running into a (live lock?) issue on our production Postgres
> > instance causing queries referencing a particular table to become
> extremely
> > slow and our application to lock up.
>
> Livelock? Really? That would imply that the query would never finish.
> A livelock is morally equivalent to an undetected deadlock.
>
Livelock is bad term.
> > This tends to occur on a particular table that gets a lot of queries
> against
> > it after a large number of deletes. When this happens, the following
> > symptoms occur when queries referencing that table are run (even it we
> stop
> > the deleting):
> >
> > SELECT * FROM table_name LIMIT 10; -- takes ~45 seconds to complete
> > EXPLAIN SELECT * FROM table_name LIMIT 10; -- takes ~45 seconds to
> complete
> > the explain query, the query plan looks reasonable
> > EXPLAIN SELECT * FROM table_name LIMIT 10; -- takes ~45 seconds to
> complete
> > the explain analyze query, query plan looks reasonable, timing stats says
> > query took sub millisecond time to complete
>
> Why should explain analyze say that? You'd need to catch the problem
> as it is run.
>
> > SELECT * FROM another_table LIMIT 10; -- takes sub millisecond time
> > EXPLAIN * FROM another_table LIMIT 10; -- takes sub millisecond time,
> query
> > plan looks reasonable
> >
> > This behavior only stops and the queries go back to taking sub
> millisecond
> > time if we take the application issuing the SELECTs offline and wait for
> the
> > active queries to finish (or terminate them).
> >
> > There is not a particularly large load on the database machine at the
> time,
> > neither are there a particularly large number of wal logs being written
> > (although there is a burst of wal log writes immediately after the queue
> is
> > cleared).
>
> Are you aware of hint bits?
>
> https://wiki.postgresql.org/wiki/Hint_Bits
No, but why would this cause the EXPLAIN queries to be slow?
>
>
> --
> Regards,
> Peter Geoghegan
>
--
Thank You,
Pweaver (pweaver(at)panjiva(dot)com)
From | Date | Subject | |
---|---|---|---|
Next Message | Pweaver (Paul Weaver) | 2014-02-05 19:47:53 | Re: Postgres Query Plan Live Lock |
Previous Message | bricklen | 2014-02-05 16:39:45 | Re: Postgres Query Plan Live Lock |