| От | Tom Lane |
|---|---|
| Тема | Re: Wrong estimation of rows for hash join |
| Дата | |
| Msg-id | 6204.1255704148@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Wrong estimation of rows for hash join (Alban Hertroys <dalroi@solfertje.student.utwente.nl>) |
| Список | pgsql-general |
Alban Hertroys <dalroi@solfertje.student.utwente.nl> writes:
> I'm also somewhat surprised to see an array of what appear to be
> integers be cast to bpchar[]. Did you define those coordinates(?) as
> character types? Numerical comparisons tend to be faster than string
> comparisons, which should make some difference on sequential scans.
Or, if the column can't be changed to an integer, at least consider
making it varchar not char. The funny rules about trailing blanks
make char comparison a bit slower than varchar, IIRC. They aren't
very conducive to fast hashing either ...
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера