| От | Pierre-Frédéric Caillaud |
|---|---|
| Тема | Re: LIMIT causes SEQSCAN in subselect |
| Дата | |
| Msg-id | opsjholqqlcq72hf@musicbox обсуждение исходный текст |
| Ответ на | Re: LIMIT causes SEQSCAN in subselect (Josh Berkus <josh@agliodbs.com>) |
| Список | pgsql-performance |
> The fact that the estimator knows that the LIMIT is pointless because
> there
> are less rows in the subselect than the LIMIT will return is not
> something we
> want to count on; sometimes the estimator has innaccurate information.
> The
> UNIQUE index makes this more certain, except that I'm not sure that the
> planner distinguishes between actual UNIQUE indexes and columns which are
> estimated unique (per the pg_stats). And I think you can see in your
> case
> that there's quite a difference between a column we're CERTAIN is unique,
> versus a column we THINK is unique.
I think a UNIQUE constraint can permit several 'different' NULL values...
better say "UNIQUE NOT NULL" ?
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера