Re: [pgsql-ru-general] Re: [pgsql-ru-general] Частично уникальное поле

13 марта 2011 г. 3:48 пользователь Nikolay Samokhvalov <
samokhvalov(at)gmail(dot)com> написал:

> 2011/3/13 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
>
>> Приветствую,
>>
>> 13 марта 2011 г. 2:54 пользователь Nikolay Samokhvalov <
>> samokhvalov(at)gmail(dot)com> написал:
>>
>>> Уникальный индекс -- это уже и есть ограничение целостности. Можно ещё
>>> раз повторю? И ещё, на ночь, чтобы запомнилось.
>>>
>> ...
>>
> or group of columns used in the constraint.". Надеюсь, что после этого Вы
>> не станете
>> утверждать, что ограничение уникальности является уникальным (btree)
>> индексом.
>> Я всегда ратовал и буду ратовать за корректность.
>>
>
> Ни разу такого не утверждал.
> Раз любите корректность, включите ещё логику)
> Из "А является Б" вовсе не следует утверждение "Б является А".
>
О чем вообще тут может быть речь? Читайте внимательно 5.3.3 документации.
Вы правы по своему в том смысле, что ограничение уникальности, создаваемое
ключевым словом UNIQUE, _обеспечивается_ с помощью уникального индекса,
который для этого и создаётся.
А вообще, ограничение уникальности можно обеспечить и без создания индекса -
триггером. Сложно, но можно.

>
>
>>
>>> Для новичков нужно запоминать именно так, чтобы как раз и не возникало
>>> вопросов "а как создать constraint".
>>>
>> Ой, да ладно про "спец курсы для новичков". :-)
>>
>
> Не смешно. Порог входа у Постгреса очень высокий. И чем больше мы стараемся
> умничать, тем выше он становится.
>
Порог такой, какой он есть. Кто захочет, тот осилит. А умничаем мы тогда,
когда несём отсебятину, а не ссылаемся на скрупулезно составляемую,
великолепную документацию.

>
>
>>
>>> Про размер индекса -- верно, частичный индекс экономит место, если
>>> NULL-ов ожидается много. Но при этом надо понимать, что будут последствия
>>> для оптимайзера (всё же это индекс и он может пригодиться не только как
>>> ограничение целостности).
>>>
>> Какие такие последствия?
>>
>
> Берём две таблички
>
> m=# \d a
> Table "public.a"
> Column | Type | Modifiers
> --------+---------+-----------
> num | integer |
> txt | text |
> Indexes:
> "a_txt_key" UNIQUE, btree (txt)
>
> m=# \d b
> Table "public.b"
> Column | Type | Modifiers
> --------+---------+-----------
> num | integer |
> txt | text |
> Indexes:
> "u_b" UNIQUE, btree (txt) WHERE txt IS NOT NULL
>
> Заполняем данными
> m=# insert into a select 1, random()::text from generate_series(1, 10000);
> INSERT 0 10000
> m=# insert into a select 1, NULL from generate_series(1, 1000);
> INSERT 0 1000
> m=# insert into b select 1, random()::text from generate_series(1, 10000);
> INSERT 0 10000
> m=# insert into b select 1, NULL from generate_series(1, 1000);
> INSERT 0 1000
>
>
> Ну и финальное, перед сном)
>
> m=# explain select * from a order by txt limit 10;
> QUERY PLAN
>
>
> -------------------------------------------------------------------------------
> Limit (cost=0.00..0.84 rows=10 width=36)
> -> Index Scan using a_txt_key on a (cost=0.00..711.56 rows=8487
> width=36)
> (2 rows)
>
> m=# explain select * from b order by txt limit 10;
> QUERY PLAN
> --------------------------------------------------------------------
> Limit (cost=416.71..416.73 rows=10 width=36)
> -> Sort (cost=416.71..444.21 rows=11000 width=36)
> Sort Key: txt
> -> Seq Scan on b (cost=0.00..179.00 rows=11000 width=36)
> (4 rows)
>
> Это последствия? Я думал, что это результат работы парсера :-)

--
// Dmitriy.