Re: reducing number of ANDs speeds up query RESOLVED - Mailing list pgsql-general

From Jeff Janes
Subject Re: reducing number of ANDs speeds up query RESOLVED
Date
Msg-id CAMkU=1x-wKNWgKDZi5sDhi4o12OMW1Q8P5L8yjt3Vs+4VwSNLw@mail.gmail.com
Whole thread Raw
In response to Re: reducing number of ANDs speeds up query RESOLVED  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reducing number of ANDs speeds up query RESOLVED
List pgsql-general
On Tue, Jan 15, 2013 at 7:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "T. E. Lawrence" <t.e.lawrence@icloud.com> <CAMkU=1y6UuxPYbf_ky8DVDsJi=g=uQ1t0B6kwLEtdc7NLxB_-Q@mail.gmail.com>
writes:
>> On 15.01.2013, at 05:45, Jeff Janes <jeff.janes@gmail.com> wrote:
>>>> Is the autovacuum 100% reliable in relation to VACUUM ANALYZE?
>
>>> No.  For example, if you constantly do things that need an access exclusive lock, then autovac will keep getting
interruptedand never finish. 
>
>> I see.
>
>> So, apparently, we need to interrupt the heavy imports on some reasonable intervals and do manual VACUUM ANALYZE?
>
> Data import as such, no matter how "heavy", shouldn't be a problem.
> The question is what are you doing that takes access-exclusive table
> locks frequently, and do you really need to do that?
>
> A quick look at the docs suggests that ALTER TABLE, REINDEX, or CLUSTER
> would be the most likely candidates for taking exclusive table locks.

But that isn't an exhaustive list--weaker locks will also cancel
autovacuum, for example I think the SHARE lock taken by CREATE INDEX
will and the even weaker one taken by CREATE INDEX CONCURRENTLY will
too.

But will all of those cancel auto-analyze as well as auto-vac?  I
guess they will because they use the same lock level.

T.E., Fortunately in point releases from August 2012 (9.0.9, 9.1.5,
etc.), the default server log settings will log both the cancel and
the command triggering the cancel.  So if you are running an up to
date server, you can just look in the logs to see what is happening.

Cheers,

Jeff


pgsql-general by date:

Previous
From: ning chan
Date:
Subject: Re: Streaming Replication
Next
From: "Gauthier, Dave"
Date:
Subject: Re: Recommendations on plpgsql debugger?