From: | "Say42" <andrews42(at)yandex(dot)ru> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimizer improvements: to do or not to do? |
Date: | 2006-09-14 04:47:14 |
Message-ID: | 1158209234.024196.302450@m73g2000cwd.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I'm having a hard time getting excited about improving this query when
> it's so badly coded in the first place. What's an ORDER BY doing in
> an EXISTS subquery? The LIMIT is unnecessary too. And the inner WHERE
> says nothing so much as "I don't know how to design a database" :-(.
It was the test query which has the same execution plan for belg_mobile
(and the same problem) as the production query below:
select (select max(code) from belg_mobile tc
where c.bnum >= tc.code and c.bnum like tc.code || '%') as code,
c.cause,
c.ilno,
extract(hour from c.datetime) as hour,
count(*) as cnt,
sum(c.dur) as dur
from conn.conn20060803 c
where itgrp = :itgrp
group by 1,2,3,4
It's a simple OLAP query for analysis telephonic traffic distribution
over time and trunk codes.
'max(codes)' is used to get the most matching code. For example,
84725 and 8472 are both valid codes, and number 84725123456 must match
84725 but not 8472. The 'c.bnum >= tc.code' qual significantly reduce
index scan and execution time.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-09-14 05:12:33 | Draft release notes |
Previous Message | Theo Schlossnagle | 2006-09-14 03:34:06 | Interesting tight loop |