Re: Optimizer improvements: to do or not to do?

Поиск
Список
Период
Сортировка
От Say42
Тема Re: Optimizer improvements: to do or not to do?
Дата
Msg-id 1158209234.024196.302450@m73g2000cwd.googlegroups.com
обсуждение исходный текст
Ответ на Re: Optimizer improvements: to do or not to do?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Theo Schlossnagle
Дата:
Сообщение: Interesting tight loop
Следующее
От: Bruce Momjian
Дата:
Сообщение: Draft release notes