> I'd suggest to increase the value up to ~80MB, if not for the system,
> may be just for the session running this query.
> Then see if performance improved.
Don't forget you can do this for the given query without affecting the
other queries - just do something like
SET work_mem = 128M
and the
> -Original Message-
> From: Patrick Donlin [mailto:pdon...@oaisd.org]
> Sent: Thursday, July 15, 2010 11:13 AM
> To: Kevin Grittner; pgsql-performance@postgresql.org
> Subject: Re: Identical query slower on 8.4 vs 8.3
>
> I'll read over that wiki entry, but for now here is the
> EXPL
"Patrick Donlin"
Cc: "Kevin Grittner" ,
pgsql-performance@postgresql.org
Sent: Thursday, July 15, 2010 12:04:13 PM GMT -05:00 US/Canada Eastern
Subject: Re: [PERFORM] Identical query slower on 8.4 vs 8.3
your plans are identical as is the runtime basically. this means you
m
On Thu, 2010-07-15 at 10:41 -0400, Patrick Donlin wrote:
> Results when running on the v8.3.7 server
> Total query runtime: 32185 ms.
> 700536 rows retrieved.
>
> Results when running on the v8.4.4 server
> Total query runtime: 164227 ms.
> 700536 rows retrieved.
>
>
> Anyone have any
On Thu, Jul 15, 2010 at 11:12 AM, Patrick Donlin wrote:
> I'll read over that wiki entry, but for now here is the EXPLAIN ANALYZE
> output assuming I did it correctly. I have run vacuumdb --full --analyze,
> it actually runs as a nightly cron job.
>
> 8.4.4 Sever:
> "Unique (cost=202950.82..22752
Patrick Donlin wrote:
> I have run vacuumdb --full --analyze, it
> actually runs as a nightly cron job.
That's usually not wise -- VACUUM FULL can cause index bloat, and is
not normally necessary. If you have autovacuum turned on and run a
database vacuum each night, you can probably avoid
On Thu, Jul 15, 2010 at 9:41 AM, Patrick Donlin wrote:
> I have two servers with equal specs, one of them running 8.3.7 and the new
> server running 8.4.4. The only tweak I have made from the default install
> (from Ubuntu repositories) is increasing shared_buffers to 768MB. Both
> servers are run
ash (cost=2.60..2.60 rows=60 width=21) (actual time=0.112..0.112
rows=60 loops=1)"
" -> Seq Scan on test (cost=0.00..2.60 rows=60 width=21) (actual
time=0.035..0.069 rows=60 loops=1)"
"Total runtime: 23462.639 ms"
Thanks for the quick responses and being patient with me not prov
Excerpts from Patrick Donlin's message of jue jul 15 11:12:53 -0400 2010:
> I'll read over that wiki entry, but for now here is the EXPLAIN ANALYZE
> output assuming I did it correctly. I have run vacuumdb --full --analyze, it
> actually runs as a nightly cron job.
These plans seem identical (t
60 loops=1)"
"Total runtime: 23462.639 ms"
Thanks for the quick responses and being patient with me not providing enough
information.
-Patrick
- Original Message -
From: "Kevin Grittner"
To: "Patrick Donlin" , pgsql-performance@postgresql.org
Sent:
Patrick Donlin wrote:
> Anyone have any ideas on where I should start looking to figure
> this out?
You're going to want to run EXPLAIN ANALYZE for the slow query on
both servers. If you want the rest of us to be able to contribute
ideas, we'll need a little more information -- please read th
On 15 July 2010 15:41, Patrick Donlin wrote:
> I have two servers with equal specs, one of them running 8.3.7 and the new
> server running 8.4.4. The only tweak I have made from the default install
> (from Ubuntu repositories) is increasing shared_buffers to 768MB. Both
> servers are running 64-bi
I have two servers with equal specs, one of them running 8.3.7 and the new
server running 8.4.4. The only tweak I have made from the default install (from
Ubuntu repositories) is increasing shared_buffers to 768MB. Both servers are
running 64-bit, but are different releases of Ubuntu.
This is
13 matches
Mail list logo
