Matthew Schumacher <[EMAIL PROTECTED]> writes:
> Here is the proc that has very inconsistent (anywhere from 25ms to
> 8000ms) performance:
> ...
> This setup, with concurrency, is returning very inconsistent query
> performance. Sometimes its very fast, other times it's slow and waits.
> This mak
Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
>> From what you described, I would not expect many locking problems. Are
>> there any other types of queries you run that may cause a lock?
>
> Row locks (SELECT FOR UPDATE/SHARE) are a possible problem, particularly
> if this is a pre-8.1
Matthew Schumacher <[EMAIL PROTECTED]> writes:
> I have "autovacuum = on" in the config file with a pretty frequent
> autovacuum_naptime, but I'm unsure if that does a vacuum or vacuum full.
autovacuum *never* does a vacuum full, because that would lead to
unexpected blockages of foreground querie
Jeff Davis <[EMAIL PROTECTED]> writes:
> From what you described, I would not expect many locking problems. Are
> there any other types of queries you run that may cause a lock?
Row locks (SELECT FOR UPDATE/SHARE) are a possible problem, particularly
if this is a pre-8.1 Postgres where exclusive r
Jeff Davis wrote:
> http://www.postgresql.org/docs/8.1/static/mvcc.html
>
> In the "Explicit Locking" section it details the locks acquired by
> UPDATE, etc.
>
>>From what you described, I would not expect many locking problems. Are
> there any other types of queries you run that may cause a lock
On Thu, 2006-08-31 at 11:04 -0800, Matthew Schumacher wrote:
> Tom Lane wrote:
> > Matthew Schumacher <[EMAIL PROTECTED]> writes:
> >> I have been having performance problems with my DB so this morning I
> >> added some config to log queries that take more than 250ms. The result
> >> is surprising
Tom Lane wrote:
> Matthew Schumacher <[EMAIL PROTECTED]> writes:
>> I have been having performance problems with my DB so this morning I
>> added some config to log queries that take more than 250ms. The result
>> is surprising because some queries will take as long as 10 seconds, but
>> then you
Matthew Schumacher <[EMAIL PROTECTED]> writes:
> I have been having performance problems with my DB so this morning I
> added some config to log queries that take more than 250ms. The result
> is surprising because some queries will take as long as 10 seconds, but
> then you do a explain analyze o
I have been having performance problems with my DB so this morning I
added some config to log queries that take more than 250ms. The result
is surprising because some queries will take as long as 10 seconds, but
then you do a explain analyze on them they show that indexes are being
used and they r
