Re: PoC: prefetching index leaf pages (for inserts)
От | Tomas Vondra |
---|---|
Тема | Re: PoC: prefetching index leaf pages (for inserts) |
Дата | |
Msg-id | ed3c7097-dbb2-ec28-d2f7-6506b2b06176@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: PoC: prefetching index leaf pages (for inserts) (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: PoC: prefetching index leaf pages (for inserts)
Re: PoC: prefetching index leaf pages (for inserts) |
Список | pgsql-hackers |
Seems cfbot was not entirely happy about the patch, for two reasons: 1) enable_insert_prefetching definition was inconsistent (different boot/default values, missing in .conf and so on) 2) stupid bug in execReplication, inserting index entries twice The attached v3 should fix all of that, I believe. As for the path forward, I think the prefetching is demonstrably beneficial. There are cases where it can't help or even harms performance. I think the success depends on three areas: (a) reducing the costs of the prefetching - For example right now we build the index tuples twice (once for prefetch, once for the insert), but maybe there's a way to do that only once? There are also predicate indexes, and so on. (b) being smarter about when to prefetch - For example if we only have one "prefetchable" index, it's somewhat pointless to prefetch (for single-row cases). And so on. (c) not prefetching when already cached - This is somewhat related to the previous case, but perhaps it'd be cheaper to first check if the data is already cached. For shared buffers it should not be difficult, for page cache we could use preadv2 with RWF_NOWAIT flag. The question is if this is cheap enough to be cheaper than just doing posix_fadvise (which however only deals with shared buffers). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: