Hello all,
Just wanted to share some results from some very basic benchmarking
runs comparing three disk configurations on the same hardware:
http://morefoo.com/bench.html
Before I launch into any questions about the results (I don't see
anything particularly shocking here), I'll describe the
I changed the configuration in postgresql.conf. Following are the
changed parameters:
shared_buffers = 1GB
maintenance_work_mem = 50MB
checkpoint_segments = 64
wal_buffers = 5MB
autovacuum = off
Insert the records in the database and got a very good performance it
is increased by 6 times.
Can
On 31 Leden 2012, 10:29, Saurabh wrote:
I changed the configuration in postgresql.conf. Following are the
changed parameters:
shared_buffers = 1GB
maintenance_work_mem = 50MB
checkpoint_segments = 64
wal_buffers = 5MB
autovacuum = off
Insert the records in the database and got a very
Hello,
I have a weird table, upon with the queries are much faster when no
statics were collected.
Is there a way to delete statistics information for a table ?
I've tried ALTER.. set STATISTICS 0 and then run ANALYZE, but it seems
that old statistics are kept this way.
Can I delete entries
On 1/31/12 3:50 AM, Marc Mamin wrote:
Hello,
I have a weird table, upon with the queries are much faster when no
statics were collected.
Is there a way to delete statistics information for a table ?
I've tried ALTER.. set STATISTICS 0 and then run ANALYZE, but it seems
that old
Shared buffers is the cache maintained by PostgreSQL. All all the data
that you read/write need to go through shared buffers.
While this is technically true, I need to point out that you generally
increase shared_buffers for high concurrency, and for reads, not for
writes, especially for
Hello,
Some more tests have shown that removing the statistics just move the
performance issue to other places.
The main issue here is a bad design, so I'd better focus on this than losing
too much time with the current situation.
But this raises an interesting question on how/where does
On Tue, Jan 31, 2012 at 12:46 PM, Josh Berkus j...@agliodbs.com wrote:
Shared buffers is the cache maintained by PostgreSQL. All all the data
that you read/write need to go through shared buffers.
While this is technically true, I need to point out that you generally
increase shared_buffers
On Mon, Jan 30, 2012 at 3:11 AM, Ron Arts ron.a...@gmail.com wrote:
Op 30-01-12 02:52, Jose Ildefonso Camargo Tolosa schreef:
On Sun, Jan 29, 2012 at 6:18 PM, Ron Arts ron.a...@gmail.com wrote:
Hi list,
I am running PostgreSQL 8.1 (CentOS 5.7) on a VM on a single XCP
(Xenserver) host.
This
My slow query today is somewhat more complex than yesterday's, but I'm
hopeful it can be improved. Here's the query:
SELECT relname, emotion, COUNT(feedback_id) FROM pg_class, moments
JOIN emotions USING (moment_id)
WHERE moments.inserted 'today' AND moments.tableoid = pg_class.oid
GROUP BY
Looks like I missed a key sentence in
http://www.postgresql.org/docs/9.0/static/ddl-inherit.html which states: A
serious limitation of the inheritance feature is that indexes (including
unique constraints) and foreign key constraints only apply to single
tables, not to their inheritance children.
I changed the query a bit so the results would not change over the
course of the day to:
SELECT relname, emotion, COUNT(feedback_id) FROM pg_class, moments
JOIN emotions USING (moment_id)
WHERE moments.inserted BETWEEN 'yesterday' AND 'today' AND
moments.tableoid = pg_class.oid
GROUP BY relname,
I just got a pointer on presenting EXPLAIN ANALYZE in a more human friendly
fashion (thanks, Agent M!): http://explain.depesz.com/s/A9S
From this it looks like the bottleneck happens when Postgres does an Index
Scan using emotions_moment_id_idx on emotions before filtering on
moments.inserted so
On Tue, Jan 31, 2012 at 10:46 AM, Josh Berkus j...@agliodbs.com wrote:
Shared buffers is the cache maintained by PostgreSQL. All all the data
that you read/write need to go through shared buffers.
While this is technically true, I need to point out that you generally
increase shared_buffers
On Mon, Jan 30, 2012 at 9:46 AM, Saurabh saurabh@gmail.com wrote:
I can not create the index after insertion because user can
search the data as well while insertion.
Remember, DDL is transactional in PostgreSQL. In principle, you
should be able to drop the index, do your inserts, and
On Wed, Feb 1, 2012 at 12:29 AM, Rosser Schwarz
rosser.schw...@gmail.com wrote:
Remember, DDL is transactional in PostgreSQL. In principle, you
should be able to drop the index, do your inserts, and re-create the
index without affecting concurrent users, if you do all of that inside
an
On Wed, Feb 1, 2012 at 12:49 AM, Claudio Freire klaussfre...@gmail.com wrote:
On Wed, Feb 1, 2012 at 12:29 AM, Rosser Schwarz
rosser.schw...@gmail.com wrote:
Remember, DDL is transactional in PostgreSQL. In principle, you
should be able to drop the index, do your inserts, and re-create the
17 matches
Mail list logo
