From: Richard Huxton <dev@archonet.com>
To: Jim C. Nasby <jim@nasby.net>
Cc: Jens Schipkowski <jens.schipkowski@apus.co.at>
Cc: pgsql-performance@postgresql.org
Subject: Re: DB Performance decreases due to often written/accessed
Date: Thu, 19 Oct 2006 19:00:28 +0100
Message-ID: <4537BD3C.7090402@archonet.com> (raw)
In-Reply-To: <20061019172249.GT71084@nasby.net>
References: <op.thn5e4sj81rjf6@xjens.apus.local>
<453791E6.4020600@archonet.com>
<op.thohq8zj81rjf6@xjens.apus.local>
<4537B394.9000205@archonet.com>
<20061019172249.GT71084@nasby.net>
Jim C. Nasby wrote:
> On Thu, Oct 19, 2006 at 06:19:16PM +0100, Richard Huxton wrote:
>> OK - these plans look about the same, but the time is greatly different.
>> Both have rows=140247 as the estimated number of rows in tbl_reg. Either
>> you have many more rows in the second case (in which case you're not
>> running ANALYSE enough) or you have lots of gaps in the table (you're
>> not running VACUUM enough).
>
> Look closer... the actual stats show that the sorts in the second case
> are returning far more rows. And yes, analyze probably needs to happen.
The results are different, I agree, but the plans (and estimates) are
the same. Given the deletes and inserts I wasn't sure whether this was
just lots more rows or a shift in values.
>> I'd then try putting an index on (attr1,attr2,attr3...attr6) and see if
>> that helps reduce time.
>
> With bitmap index scans, I think it'd be much better to create 6 indexes
> and see which ones actually get used (and then drop the others).
Good idea.
--
Richard Huxton
Archonet Ltd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dev@archonet.com, jim@nasby.net, jens.schipkowski@apus.co.at
Subject: Re: DB Performance decreases due to often written/accessed
In-Reply-To: <4537BD3C.7090402@archonet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox