Re: Performance again

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: Mihai Gheorghiu <tanethq(at)earthlink(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance again
Date: 2002-09-16 23:07:21
Message-ID: Pine.LNX.4.21.0209162342510.599-100000@ponder.fairway2k.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 16 Sep 2002, Mihai Gheorghiu wrote:

> [edited for brevity]
>
> Total runtime: 26575.85 msec
>
> vacuum verbose analyze tbas_transactions;
>
> After that, the run time for the query became 22.3s (not enough improvement
> over what
> explain analyze came up with).
>
> Looking forward to your comments,

So it sounds like the data has been taken from cache, to sime extend, or the
planner has switched to a sequential scan. My money is on the second of these,
you need to do another EXPLAIN [ANALYZE] to confirm this. The speed improvement
isn't great so I'd say that you're lucky that the nature of the data load gave
an index scan that took as short a time as it did.

The sort does seem to be taking a while. It is done to perform the GROUP
BY. I don't think there is a way to avoid it although you could try using an
index something like:

CREATE INDEX anotherindex
ON tbas_transactions (trxtype, account)
WHERE isposted = true;

I really don't know if that's going to enable the sort stage to be skipped
although if anything can I would have thought that would.

--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Glen Eustace 2002-09-16 23:30:26 Re: Panic - Format has changed
Previous Message Darren Ferguson 2002-09-16 23:06:24 Re: plperl.so