Yes, it was the same DB so, yes 8.1 gives roughly a four fold improvement (assuming hardware and OS differences aren't that significant - I'd expect the Linux version to be faster if anything); which certainly ain't bad! :)
Good idea for the vacuumdb -a -v on the laptop, I re imported the databa
On Tue, 11 Jul 2006, Jeff Frost wrote:
On Wed, 12 Jul 2006, Neil Hepworth wrote:
You might also want to turn on autovacuum and see if that helps.
What's your disk subsystem like? In fact, what's the entire DB server
hardware like?
By the way, how big does the temp table get? If it's large
On Wed, 12 Jul 2006, Neil Hepworth wrote:
I am using version PostgreSQL 7.3.10 (RPM:
postgresql73-rhel21-7.3.10-2). Unfortunately vacuumdb -a -v does not
give the FSM info at the end (need a newer version of postgres for
that). Running the same queries on 8.1 reduces the time taken to
about 16
Thanks for the tip; I'll try that when we initially upgrade, hopefully soon.
Neil
On 12/07/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
On Mon, Jul 10, 2006 at 17:55:38 +1000,Neil Hepworth <[EMAIL PROTECTED]
> wrote:>> running on our server (obviously we need to update certain queries,> e.g. d
On Mon, Jul 10, 2006 at 17:55:38 +1000,
Neil Hepworth <[EMAIL PROTECTED]> wrote:
>
> running on our server (obviously we need to update certain queries,
> e.g. delete .. using.. and test with 8.1 first) - I will be pushing
> for an upgrade as soon as possible. And the fsync=false is a
You can
Best regards,
Jamal
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
> There have been dozens, perhaps hundreds, of entries in the
> pg-admin, pg-general, and pg-performance lists regarding
> killing a session, but as far as I can tell, there is no
> Postgres solution. Did I miss something?
>
> This raises the question: Why doesn't Postgres have a "kill
> sess
Craig A. James wrote:
There have been dozens, perhaps hundreds, of entries in the pg-admin,
pg-general, and pg-performance lists regarding killing a session, but as
far as I can tell, there is no Postgres solution. Did I miss something?
This raises the question: Why doesn't Postgres have a "k
There have been dozens, perhaps hundreds, of entries in the pg-admin,
pg-general, and pg-performance lists regarding killing a session, but as far as
I can tell, there is no Postgres solution. Did I miss something?
This raises the question: Why doesn't Postgres have a "kill session" command th
