Re: [GENERAL] Vacuum time degrading
| От | Tom Lane |
|---|---|
| Тема | Re: [GENERAL] Vacuum time degrading |
| Дата | |
| Msg-id | 14630.1112720384@sss.pgh.pa.us обсуждение |
| Список | pgsql-hackers |
Wes <wespvp@syntegra.com> writes:
> Ok, now I follow. Taking the biggest indexes:
> The weekend before:
> INFO: index "message_recipients_i_recip_date" now contains 393961361 row
> versions in 2435100 pages
> INFO: index "message_recipients_i_message" now contains 393934394 row
> versions in 1499853 pages
> After reindex:
> INFO: index "message_recipients_i_recip_date" now contains 401798357 row
> versions in 1765613 pages
> INFO: index "message_recipients_i_message" now contains 401787237 row
> versions in 1322974 pages
OK, that's certainly not a factor-of-four difference in size, so I'm
now convinced you're right: bringing the index into physical order is
having a big impact on the runtime.
From a development standpoint, that suggests a couple of TODO items:
* Look harder at whether VACUUM can scan the index in physical instead
of logical order.
* See whether ordinary btree maintenance (ie page splits) can do
anything to maintain/improve the physical ordering of the index.
regards, tom lane
В списке pgsql-hackers по дате отправления: