Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > With our set of 4 DBs, that amounts to once every 40 minutes for
> > the given database. I see "LOG: autovacuum: processing
> > database "xyz"" in the log, but I do not see any analyze/vacuum
> > commands being issued at all (does it lo
On Mar 31, 2006, at 1:51 PM, Ed L. wrote:
This indeed appears to be locking problem from within
Apache::Session where it deletes a row from the DB but fails to
commit the change for an extended period while another
And you should read well the notes in the Pg driver for
Apache::Session wher
On Sunday March 26 2006 9:16 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I see what appear to be many single transactions holding
> > RowExclusiveLocks for sometimes 40-50 seconds while their
> > query shows " in transaction".
> > ...
> > I'm thinking that means the client is simp
On Sunday March 26 2006 9:14 am, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > With our set of 4 DBs, that amounts to once every 40 minutes
> > for the given database. I see "LOG: autovacuum: processing
> > database "xyz"" in the log, but I do not see any
> > analyze/vacuum commands b
On Sun, Mar 26, 2006 at 11:27:33AM -0500, Matthew T. O'Connor wrote:
> The table has 6800 rows over 18000 pages, and is getting a
> minimum of many tens of thousands of updates per day with
> queries like this:
> >>>If you're updating that much, how often are you running
> >>>'analyze'?
The table has 6800 rows over 18000 pages, and is getting a
minimum of many tens of thousands of updates per day with
queries like this:
If you're updating that much, how often are you running
'analyze'? Are you running autovacuum? How often?
I count on the built-in autovacuum to do do analyzes (
"Ed L." <[EMAIL PROTECTED]> writes:
> I see what appear to be many single transactions holding
> RowExclusiveLocks for sometimes 40-50 seconds while their query
> shows " in transaction".
> ...
> I'm thinking that means the client is simply tweaking a row and
> then failing to commit the change
"Ed L." <[EMAIL PROTECTED]> writes:
> With our set of 4 DBs, that amounts to once every 40 minutes for
> the given database. I see "LOG: autovacuum: processing
> database "xyz"" in the log, but I do not see any analyze/vacuum
> commands being issued at all (does it log when it
> analyzes/vacu
On Sunday March 26 2006 7:22 am, Ed L. wrote:
> On Saturday March 25 2006 9:55 pm, chris smith wrote:
> > On 3/26/06, Ed L. <[EMAIL PROTECTED]> wrote:
> > > On Saturday March 25 2006 9:36 pm, Ed L. wrote:
> > > > I have a performance riddle, hoping someone can point me
> > > > in a helpful directio
On Saturday March 25 2006 9:55 pm, chris smith wrote:
> On 3/26/06, Ed L. <[EMAIL PROTECTED]> wrote:
> > On Saturday March 25 2006 9:36 pm, Ed L. wrote:
> > > I have a performance riddle, hoping someone can point me
> > > in a helpful direction. We have a pg 8.1.2 cluster using
> > > Apache::Sessi
On 3/26/06, Ed L. <[EMAIL PROTECTED]> wrote:
> On Saturday March 25 2006 9:36 pm, Ed L. wrote:
> > I have a performance riddle, hoping someone can point me in a
> > helpful direction. We have a pg 8.1.2 cluster using
> > Apache::Sessions and experiencing simple UPDATEs taking
> > sometimes 30+ sec
On Saturday March 25 2006 9:49 pm, Ed L. wrote:
> On Saturday March 25 2006 9:36 pm, Ed L. wrote:
> > I have a performance riddle, hoping someone can point me in
> > a helpful direction. We have a pg 8.1.2 cluster using
> > Apache::Sessions and experiencing simple UPDATEs taking
> > sometimes 30+
On Saturday March 25 2006 9:36 pm, Ed L. wrote:
> I have a performance riddle, hoping someone can point me in a
> helpful direction. We have a pg 8.1.2 cluster using
> Apache::Sessions and experiencing simple UPDATEs taking
> sometimes 30+ seconds to do a very simply update, no foreign
> keys, no
13 matches
Mail list logo
