Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / засада с выразительными индексами / 3 сообщений из 3, страница 1 из 1
13.01.2005, 14:04
    #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, 19:06
    #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
| Ответить | Цитировать | Написать  
14.01.2005, 10:22
    #32864489
assa
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
засада с выразительными индексами
сиба. Я где-то так и думал. Просто еще не решил, как и что буду считать. (денормализованная база с таблицей промежуточных результатов по группам, которая должна пересчитываться при изменениях в любой из 3-х таблиц - курсов, величин, структуры - каша получаецца, если на триггерах. А если считать на лету - нужно считать быстро группировки ~2-го уровня вложенности + по древовидной структуре. Тоже малореально.)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / засада с выразительными индексами / 3 сообщений из 3, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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