Re: TOAST performance (was Re: [GENERAL] Delete Performance)
В списке pgsql-hackers по дате отправления:
| От | Josh Rovero |
|---|---|
| Тема | Re: TOAST performance (was Re: [GENERAL] Delete Performance) |
| Дата | |
| Msg-id | 3BF5C0F8.1060108@sonalysts.com обсуждение исходный текст |
| Ответ на | TOAST performance (was Re: [GENERAL] Delete Performance) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Tom Lane wrote > >I did some experimentation here and found a rather surprising >dependency: the time to delete a bunch of data is pretty much >directly proportional to the disk space it occupies. This says >that we're paying through the nose for having XLOG make copies >of about-to-be-modified pages. > At least now I know I wasn't imagining things.... :-) Which brings up the question, what is the best way to deal with many thousands of variable-length binary chunks. Net input == net output over the course of a day. The new vacuum should help (both lo_ and toasted tables take a long time to vacuum full), but I'm running into the "Hotel California" situation. Data goes in fast, but can't be deleted fast enough to keep the database from continuously growing in size.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера