ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / засада с выразительными индексами
3 сообщений из 3, страница 1 из 1
засада с выразительными индексами
    #32863231
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
хотел в 7.3.4.:
Код: plaintext
1.
2.
3.
CREATE INDEX leaf_ayear
   ON public.leaf 
USING btree
((date/ 10000 ::int2));
ругацца

Прорыл справку к пгАдмину (доку к 7.4. бета). Нигде ниче нет.
Залез в http://www.postgresql.org/docs/manuals/
нашел что дока к 7.4 отличается от 7.3. аккурат тем, что в
7.3. - Functional Indexes
7.4. - Indexes on Expressions

т.е. вот так у меня выходит:
Код: plaintext
1.
2.
3.
4.
CREATE INDEX leaf_ayear
   ON public.leaf 
USING btree
--((date/10000::int2));
(abs(date));
абыдна, да.

Вот че им стоило в доке зАраз пИсать, с какой версии че держится?


Теперь вопрос: Если идет группировка по ВСЕЙ таблице
в т.ч. по выражению date/10000::int2, вспоможет ли функциональный индекс (супротив индекса по date) или не поможет. (данные то все равно получатся сканом, только в группировке может быть какой-то наигрыш, да и то не вполне понятно). Т.е. заморачиваться мне с созданием псевдофункций типа ' select $1/10000::int2 ;' или даром не надь???


(хотя дело даже хуже - запрос может быть реализован и как двойной вложенности, во внутреннем которого выражения вида date/10000::int2 будут еще и в предложении WHERE - стандартные результаты на дату - т.е. в выборке, но перед группировкой, но может быть и иначе - пока думаю)
...
Рейтинг: 0 / 0
13.01.2005, 14:04
| Ответить | Цитировать | Написать  
засада с выразительными индексами
    #32864011
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
assaабыдна, да.можно так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
# select version();
                                                 version
---------------------------------------------------------------------------------------------------------
 PostgreSQL  7 . 3 . 3  on i686-pc-linux-gnu, compiled by GCC gcc (GCC)  3 . 2 . 2   20030222  (Red Hat Linux  3 . 2 . 2 - 5 )
( 1  row)
# create table foo ( bar int4 );
CREATE TABLE
# create function ffoo ( int4 ) returns int2 as 'select ($1/10000)::int2' language 'SQL' immutable;
CREATE FUNCTION
# create index ifoo on foo( ffoo( bar ) );
CREATE INDEX
# explain select * from foo where ffoo ( bar ) =  100 ::int2;
                           QUERY PLAN
----------------------------------------------------------------
 Index Scan using ifoo on foo  (cost= 0 . 00 .. 9 . 08  rows= 5  width= 4 )
   Index Cond: (ffoo(bar) =  100 ::smallint)
( 2  rows)
assaЕсли идет группировка по ВСЕЙ таблице
в т.ч. по выражению date/10000::int2, вспоможет ли функциональный индекс (супротив индекса по date) или не поможет. (данные то все равно получатся сканом, только в группировке может быть какой-то наигрыш, да и то не вполне понятно).может быть выигрыш, вот в этом плане отсутствует сортировка:
Код: plaintext
1.
2.
3.
4.
5.
6.
# explain select ffoo ( bar ), count(*) from foo group by ffoo ( bar );
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Aggregate  (cost= 0 . 00 .. 37 . 00  rows= 100  width= 4 )
   ->  Group  (cost= 0 . 00 .. 34 . 50  rows= 1000  width= 4 )
         ->  Index Scan using ifoo on foo  (cost= 0 . 00 .. 32 . 00  rows= 1000  width= 4 )
( 3  rows)
assaво внутреннем которого выражения вида date/10000::int2 будут еще и в предложении WHEREтогда индекс по ffoo поможет (см. первый explain)
...
Рейтинг: 0 / 0
13.01.2005, 19:06
| Ответить | Цитировать | Написать  
засада с выразительными индексами
    #32864489
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
сиба. Я где-то так и думал. Просто еще не решил, как и что буду считать. (денормализованная база с таблицей промежуточных результатов по группам, которая должна пересчитываться при изменениях в любой из 3-х таблиц - курсов, величин, структуры - каша получаецца, если на триггерах. А если считать на лету - нужно считать быстро группировки ~2-го уровня вложенности + по древовидной структуре. Тоже малореально.)
...
Рейтинг: 0 / 0
14.01.2005, 10:22
| Ответить | Цитировать | Написать  
3 сообщений из 3, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / засада с выразительными индексами
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]