| От | Tom Lane |
|---|---|
| Тема | Re: index row size exceeds btree maximum, 2713 - |
| Дата | |
| Msg-id | 7061.1121790363@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: index row size exceeds btree maximum, 2713 - (Scott Marlowe <smarlowe@g2switchworks.com>) |
| Список | pgsql-general |
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Tue, 2005-07-19 at 10:25, Tom Lane wrote:
>> None of the index types support entries larger than BLOCKSIZE-less-a-bit,
>> so switching to a different index type won't do more than push the
>> problem out by a factor of about 3.
> Are they compressed? It would look to me like maybe they are, or
> something strange like that. When I fed highly compressable data into
> an indexed field, it took a LOT of said text to get a failure method.
Yes, we do try to compress large index entries --- so the BLOCKSIZE or
BLOCKSIZE/3 limitation applies after compression. That's independent
of index type AFAIK. What we don't have is a TOAST table backing every
index to allow out-of-line storage ...
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера