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 по дате отправления: