Re: optimization downgrade perfomance?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: eVl <evl(dot)evl(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: optimization downgrade perfomance?
Date: 2005-09-24 03:09:09
Message-ID: 8872.1127531349@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

eVl <evl(dot)evl(at)gmail(dot)com> writes:
>> You tell us --- let's see EXPLAIN ANALYZE results for both cases.

> Here EXPLAIN ANALYZE results for both queries attached.

The problem seems to be that the is_uaix() function is really slow
(somewhere around 4 msec per call it looks like). Look at the
first scan over stats:

-> Index Scan using cdate_cluster on stats s (cost=0.00..201.51 rows=6 width=25) (actual time=5.231..2165.145 rows=418 loops=1)
Index Cond: (cdate = '2005-09-01'::date)
Filter: ((fromip << '192.168.0.0/16'::inet) AND (NOT (toip << '192.168.0.0/16'::inet)) AND (CASE is_uaix(toip) WHEN true THEN 'local'::text ELSE 'global'::text END = 'global'::text))

versus

-> Index Scan using cdate_cluster on stats s (cost=0.00..165.94 rows=1186 width=25) (actual time=0.131..43.258 rows=578 loops=1)
Index Cond: (cdate = '2005-09-01'::date)
Filter: ((fromip << '192.168.0.0/16'::inet) AND (NOT (toip << '192.168.0.0/16'::inet)))

The 578 evaluations of the CASE are adding over 2100msec. There's
another 1600 evaluations needed in the other arm of the UNION...

Better look at exactly what is_uaix() is doing, because the CASE structure
is surely not that slow.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message K C Lau 2005-09-24 03:18:24 Re: SELECT LIMIT 1 VIEW Performance Issue
Previous Message Mark Kirkwood 2005-09-24 01:40:25 Re: SELECT LIMIT 1 VIEW Performance Issue