On Wed, Feb 5, 2014 at 11:47 AM, Pweaver (Paul Weaver)
wrote:
>
> On Wed, Feb 5, 2014 at 9:52 AM, Jeff Janes wrote:
>
>> On Monday, February 3, 2014, Pweaver (Paul Weaver)
>> wrote:
>>
>>> We have been running into a (live lock?) issue on our production
>>> Postgres instance causing queries refe
On Wed, Feb 5, 2014 at 4:47 PM, Pweaver (Paul Weaver)
wrote:
>> That is quite extreme. If a temporary load spike (like from the deletes
>> and the hinting needed after them) slows down the select queries and you
>> start more and more of them, soon you could tip the system over into kernel
>> sch
On Wed, Feb 5, 2014 at 9:52 AM, Jeff Janes wrote:
> On Monday, February 3, 2014, Pweaver (Paul Weaver)
> 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 applicatio
On Tue, Feb 4, 2014 at 9:03 PM, Peter Geoghegan wrote:
> On Mon, Feb 3, 2014 at 1:35 PM, Pweaver (Paul Weaver)
> 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
On Mon, Feb 3, 2014 at 1:35 PM, Pweaver (Paul Weaver)
wrote:
>
> table_name stats:
> ~ 400,000,000 rows
> We are deleting 10,000,000s of rows in 100,000 row increments over a few
> days time prior/during this slowdown.
>
If you issue "VACUUM" or "VACUUM ANALYZE" after each DELETE, do the SELECTs
On Monday, February 3, 2014, Pweaver (Paul Weaver)
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.
>
> This tends to occur on a particular table
On Mon, Feb 3, 2014 at 1:35 PM, Pweaver (Paul Weaver)
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
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.
This tends to occur on a particular table that gets a lot of queries
against it after a large number of deletes
