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
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 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 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
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
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
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."
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
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
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
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
> 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-
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
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 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
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
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
17 matches
Mail list logo
