Message-ID: <12905186.post@talk.nabble.com>
Date: Wed, 26 Sep 2007 09:56:33 -0700 (PDT)
From: pgdba <postgresql@inbox.com>
To: pgsql-performance@postgresql.org
Subject: Re: Incorrect row estimates in plan?
In-Reply-To: <22791.1190824689@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <12902068.post@talk.nabble.com> <20944.1190817914@sss.pgh.pa.us>
	<12903194.post@talk.nabble.com> <22791.1190824689@sss.pgh.pa.us>


Tom Lane-2 wrote:
> 
> pgdba <postgresql@inbox.com> writes:
>> Tom Lane-2 wrote:
>> ->  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?
> 
>> 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).
> 
> Ah.  I didn't think you would've put such a specific thing into an index
> definition, but if you're stuck supporting such badly written queries,
> maybe there's no other way.
> 
> I rather doubt that you're going to be able to make this query any
> faster than it is, short of buying enough RAM to keep the whole table
> RAM-resident.  Pulling 80000 random rows in 1200 msec doesn't sound
> all that slow to me.
> 
> The ultimate solution might be to rethink your table designs ...
> 
> 			regards, tom lane
> 

Badly written the query may be, but I do have the opportunity to change it.
Part of the problem is that I cannot come up with a better way of writing
it.

What about the discrepancy between the estimated row count and the actual
row count for that index access?
"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)"

Is there anything I can do to influence that (not that it is likely to
change the plan, but...). I vacuumed and analyzed after I created the index,
so the stats should be at least be close (with stats target set to 1000
there).

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