for a short test purpose, I would like to see what queries are running and how
long each of them takes.by reconfiguring postgres.conf on the server level.
log_statement = 'all' is giving me the query statements.. but I don't know
where I can turn "timing" on just like what I can run from th
On a new system with 64G memory, what is the best starting points for shmmax on
OS and shared_buffers for Postgres. All databases combined are about 50G.
I want to evaluate this with the two following scenarios:
1. this machine is running only Postgres, no other applications
2. this machine ha
On a running production machine, we have 900M configured on a 16G-memory Linux
host. The db size for all dbs combined is about 50G. There are many
transactions going on all the times (deletes, inserts, updates). We do not have
a testing environment that has the same setup and the same amount of
On a Linux system, if the total memory is 4G and the shmmax is set to 4G, I
know it is bad, but how bad can it be? Just trying to understand the impact the
"shmmax" parameter can have on Postgres and the entire system after Postgres
comes up on this number.
What is the reasonable setting for
How can I tell if my work_mem configuration is enough to support all Postgres
user activities on the server I am managing?
Where do I find the indication if the number is lower than needed.
Thanks,
Jessica
side?
Thanks a lot,
Jessica
- Original Message
From: Craig Ringer <[EMAIL PROTECTED]>
To: Jessica Richard <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Sent: Friday, July 4, 2008 1:16:31 AM
Subject: Re: [PERFORM] slow delete
Jessica Richard wrote:
> I have a tab
I have a table with 29K rows total and I need to delete about 80K out of it.
I have a b-tree index on column cola (varchar(255) ) for my where clause to use.
my "select count(*) from test where cola = 'abc' runs very fast,
but my actual "delete from test where cola = 'abc';" takes forever, neve
I have a large table with about 2 million rows and it will keep growing...
I need to do update/inserts, and select as well.
An index will speed up the select, but it will slow down the updates.
Are all Postgres indexes ordered? i.e., with every update, the index pages will
have to be physically
