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 ha
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 yo
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
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 dir
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 row-
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 Postgres
On Tue, Jan 31, 2012 at 12:46 PM, Josh Berkus 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 for high c
On Mon, Jan 30, 2012 at 3:11 AM, Ron Arts wrote:
> Op 30-01-12 02:52, Jose Ildefonso Camargo Tolosa schreef:
>> On Sun, Jan 29, 2012 at 6:18 PM, Ron Arts wrote:
>>> Hi list,
>>>
>>> I am running PostgreSQL 8.1 (CentOS 5.7) on a VM on a single XCP
>>> (Xenserver) host.
>>> This is a HP server wit
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 reln
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, e
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 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 for high c
On Mon, Jan 30, 2012 at 9:46 AM, Saurabh 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 re-create the
index with
On Wed, Feb 1, 2012 at 12:29 AM, Rosser Schwarz
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 explicit transaction. Doin
On Wed, Feb 1, 2012 at 12:49 AM, Claudio Freire wrote:
> On Wed, Feb 1, 2012 at 12:29 AM, Rosser Schwarz
> 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
17 matches
Mail list logo
