pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: pgdba <postgresql@inbox.com>
To: pgsql-performance@postgresql.org
Subject: Re: Incorrect row estimates in plan?
Date: Wed, 26 Sep 2007 08:24:01 -0700 (PDT)
Message-ID: <12903194.post@talk.nabble.com> (raw)
In-Reply-To: <20944.1190817914@sss.pgh.pa.us>
References: <12902068.post@talk.nabble.com>
	<20944.1190817914@sss.pgh.pa.us>


Hi Tom,

Tom Lane-2 wrote:
> 
> pgdba <postgresql@inbox.com> writes:
>>             ->  Bitmap Heap Scan on slog  (cost=82.98..6434.62 rows=2870
>> width=61) (actual time=50.235..1237.948 rows=83538 loops=1)
>>                     Recheck Cond: ((gid = 10000) AND (rule = ANY
>> ('{1,2,8,9,10}'::integer[])) AND (CASE WHEN (rule = ANY
>> ('{8,9}'::integer[])) THEN destip ELSE srcip END =
>> '192.168.10.23'::inet))
>>                     ->  Bitmap Index Scan on slog_gri_idx 
>> (cost=0.00..82.26
>> rows=2870 width=0) (actual time=41.306..41.306 rows=83538 loops=1)
>>                         Index Cond: ((gid = 10000) AND (rule = ANY
>> ('{1,2,8,9,10}'::integer[])) AND (CASE WHEN (rule = ANY
>> ('{8,9}'::integer[])) THEN destip ELSE srcip END =
>> '192.168.10.23'::inet))
> 
> [ blink... ]  Pray tell, what is the definition of this index?
> 
> With such a bizarre scan condition, it's unlikely you'll get any really
> accurate row estimate.
> 
> 			regards, tom lane
> 
> 

Original index: "create index slog_gri_idx on slog (gid,rule,(case when rule
in (8,9) then
destip else srcip end)) WHERE (rule in (1, 2, 8, 9, 10))"

The purpose of that index is to match a specific query (one that gets run
frequently and needs to be fast). It is using the destip when rule 8/9, and
srcip when other, but only for a subset of the rules (1,2,8,9,10). There are
about 18 rules in total, but I'm only interested in those 5. I have tried a
couple of indices like:
create index test_destip_idx on slog (gid,destip) where rule in (8,9);
create index test_srcip_idx on slog (gid,srcip) where rule in (1,2,10);

But the original slog_gri_idx index was used instead. Is there a way that I
can rewrite that index then? Not that I'm a fan of a CASE statement in a
functional index, but I'm at a loss as to how else I can create this. Or
what else I can look into to make this faster?


-- 
View this message in context: http://www.nabble.com/Incorrect-row-estimates-in-plan--tf4522692.html#a12903194
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.




view thread (5+ messages)  latest in thread

Message-ID: <12903194.post@talk.nabble.com>
Permalink:  ../12903194.post@talk.nabble.com/
Also on:    postgresql.org/message-id/12903194.post@talk.nabble.com

 · 

reply

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: postgresql@inbox.com
  Subject: Re: Incorrect row estimates in plan?
  In-Reply-To: <12903194.post@talk.nabble.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