Re: Speed of lo_unlink vs. DELETE on BYTEA

Поиск
Список
Период
Сортировка
От Eduardo Morras
Тема Re: Speed of lo_unlink vs. DELETE on BYTEA
Дата
Msg-id 4E5EF2B0006440E8@
обсуждение исходный текст
Ответ на Re: Speed of lo_unlink vs. DELETE on BYTEA  ("Reuven M. Lerner" <reuven@lerner.co.il>)
Список pgsql-general
At 07:43 25/09/2011, Reuven M. Lerner wrote:

>Hi, everyone.=C2  Daniel Verite=20
><mailto:daniel@manitou-mail.org><daniel@manitou-mail.org> wrote:
>
>It would thus appear that there's a slight edge=20
>for dumping bytea, but nothing=20
>super-amazing.=C2  Deleting, however, is still=20
>much faster with bytea than large objects.

The problem you have is with=20
compression/decompression on large objects. If=20
you see at it's sizes, you get 680KB for large=20
objects and 573MB for bytea. Postgresql needs to=20
decompress them before the dump. Even worse, if=20
your dump is compressed, postgres decompress each=20
large object , dump it and recompress. For this=20
test, switch off compression on large=20
objects/toast. For long term, perhaps a request=20
to postgresql hackers to directly dump the=20
already compressed large objects. The toast maybe=20
more difficult because there are not only big=20
size columns, but any column whose* size is=20
bigger than a threshold (don't remember now, 1-2KB or similar)

* Is it whose the correct word? I hope i have expressed correctly.

EFME=20

В списке pgsql-general по дате отправления:

Предыдущее
От: Raghavendra
Дата:
Сообщение: Re: In which case PG_VERSION file updates ?
Следующее
От: Alban Hertroys
Дата:
Сообщение: Re: looking for a faster way to do that