http://www.databasejournal.com/features/postgresql/article.php/3323561
Shridhar
---(end of broadcast)---
TIP 8: explain analyze is your friend
I sent this message to the list and although it shows up in the archives,
I did not receive a copy of it through the list, so I'm resending as I
suspect others did not see it either.
-- Forwarded message --
Date: Sat, 13 Mar 2004 22:48:01 -0500 (EST)
From: Kris Jurka <[EMAIL PROTE
Matthew T. O'Connor wrote:
If memory serves, the problem is that you actually sleep 10ms even when
you set it to 1. One of the thing changed in Jan's later patch was the
ability to specify how many pages to work on before sleeping, rather
than how long to sleep inbetween every 1 page. You might b
Joe Conway <[EMAIL PROTECTED]> writes:
> I have tested Tom's original patch now. The good news -- it works great
> in terms of reducing the load imposed by vacuum -- almost to the level
> of being unnoticeable. The bad news -- in a simulation test which loads
> an hour's worth of data, even with
On Tue, 2004-03-16 at 23:49, Joe Conway wrote:
I have tested Tom's original patch now. The good news -- it works great
in terms of reducing the load imposed by vacuum -- almost to the level
of being unnoticeable. The bad news -- in a simulation test which loads
an hour's worth of data, even with
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Any idea where I can get my hands on the latest version. I found the
original post from Tom, but I thought there was a later version with
both number of pages and time to sleep as knobs.
That was as far as I got. I think Jan posted a more c
Quick observations:
1. We have an explanation for what's going on, based on the message being
exactly 666 lines long :-)
2. I'm clueless on the output, but perhaps Tom can see something. A quick
glance shows that the strace seemed to run 27 seconds, during which it did:
count| call
---|---
"Rosser Schwarz" <[EMAIL PROTECTED]> writes:
> `strace -p 21882` run behind the below query and plan ... below that.
Hmm ... that took 20 seconds eh?
It is a fairly interesting trace. It shows that the backend needed to
read 63 system catalog pages (that weren't already in shared memory),
which
while you weren't looking, Tom Lane wrote:
[trace]
`strace -p 21882` run behind the below query and plan ... below that.
# explain update account.cust set prodid = tempprod.prodid, subprodid =
tempprod.subprodid where origid = tempprod.debtid;
QUERY PLAN
---
"Rosser Schwarz" <[EMAIL PROTECTED]> writes:
> Having never more than glanced at the output of "vacuum verbose", I
> can't say whether that makes the cut for oodles. My suspicion is no.
Nope, it sure doesn't. We occasionally see people who don't know they
need to vacuum regularly and have accumu
while you weren't looking, Tom Lane wrote:
> EXPLAIN won't tell you anything about triggers that might get fired
> during the UPDATE, so it's not much help for investigating possible
> FK performance problems. EXPLAIN ANALYZE will give you some indirect
> evidence: the difference between the tota
"Rosser Schwarz" <[EMAIL PROTECTED]> writes:
> But if I'm not touching the column referenced from account.acct, why
> would it be looking there at all? I've got an explain analyze of the
> update running now, but until it finishes, I can't say for certain
> what it's doing. explain, alone, says:
This apeared on the Freebsd-perfomace list and though people here could help
as well.
-- Forwarded Message --
Subject: Configuring disk cache size on postgress
Date: March 16, 2004 10:44 am
From: Dror Matalon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi Folks,
When configur
while you weren't looking, Tom Lane wrote:
> But with the possible exception of wal_buffers, I can't see
> anything in
> these settings that explains the originally complained-of performance
> problem. I'm still wondering about foreign key checks.
Many of the configs I posted were fairly wild v
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Rosser Schwarz wrote:
>> shared_buffers = 4096
>> sort_mem = 32768
>> vacuum_mem = 32768
>> wal_buffers = 16384
>> checkpoint_segments = 64
>> checkpoint_timeout = 1800
>> checkpoint_warning = 30
>> commit_delay = 5
>> effective_cache_size = 131
15 matches
Mail list logo
