ks for your insights.
--
Benjamin Minshall
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
ut of the problem query and your postgresql.conf also.
--
Benjamin Minshall <[EMAIL PROTECTED]>
Senior Developer -- Intellicon, Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
Tom Lane wrote:
A further report led us to realize that 8.2.x in fact has a nasty bug
here: the stats collector is supposed to dump its stats to a file at
most every 500 milliseconds, but the code was actually waiting only
500 microseconds :-(. The larger the stats file, the more obvious
this pr
any unusual activity on the server, but I
have set up some more detailed logging to hopefully identify a pattern
if the problem resurfaces.
Thanks.
--
Benjamin Minshall <[EMAIL PROTECTED]>
Senior Developer -- Intellicon, Inc.
http://www.intellicon.biz
smime.p7s
Description: S/MIME Cryptographic Signature
r the file size started to
decrease soon after the nightly pg_dump backups completed. Coincidence
perhaps?
Nonetheless, I would appreciate a copy of Alvaro's stat file tool just
to see if anything stands out in the collected stats.
Thanks for your help, Tom.
--
Benjamin Minshall <[
> Benjamin Minshall <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> How many tables are visible in the pg_stats views?
>
>> There are about 15 databases in the cluster each with around 90 tables.
>> A count of pg_stats yields between 500 and 800
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Seems the problem may be related to a huge global/pgstat.stat file.
Under 8.1.5 it was about 1 MB; now it's 90 MB in 8.2.3.
Yoi. We didn't do anything that would bloat that file if it were
storing the same infor
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Can you gather some info about what it's doing?
strace'ing the stats collector might prove interesting, also if you have
built it with --enable-debug then oprofile results would be helpful.
I
when I have a chance to
shutdown the server.
Thanks.
--
Benjamin Minshall <[EMAIL PROTECTED]>
Senior Developer -- Intellicon, Inc.
http://www.intellicon.biz
smime.p7s
Description: S/MIME Cryptographic Signature
Tom Lane wrote:
Benjamin Minshall <[EMAIL PROTECTED]> writes:
Since upgrading to 8.2.3 yesterday, the stats collector process has had
very high CPU utilization; it is consuming roughly 80-90% of one CPU.
The server seems a lot more sluggish than it was before. Is this normal
operati
?
stats_start_collector = true
stats_command_string = true
stats_block_level = true
stats_row_level = true
stats_reset_on_server_start = false
--
Benjamin Minshall <[EMAIL PROTECTED]>
Senior Developer -- Intellicon, Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
f
all the ones we've tested so far.
What are your shared_buffers, work_mem, and maintenance_work_mem settings?
maintenance_work_mem is used for CREATE INDEX, and with 16GB of memory
in the machine, maintenance_work_mem should be set to at least 1GB in my
opinion.
--
Benjamin Minshall &l
would use:
SELECT ... FOR UPDATE;
IF FOUND THEN
UPDATE ...;
ELSE
INSERT ...;
END IF;
If you have multiple transactions doing this process at the same time,
you'll need explicit locking of the table to avoid a race condition.
--
Benjamin Minshall <[EMAIL PROTECTED]
he = ANY array method makes plpgsql development cleaner,
but seems to really lack performance in certain cases. What do you
recommend as the preferred method?
Thanks for your comments.
--
Benjamin Minshall <[EMAIL PROTECTED]>
Senior Developer -- Intellicon, Inc.
http://www.intellicon.biz
sm
14 matches
Mail list logo
