Re: init_sequence spill to hash table
От | Andres Freund |
---|---|
Тема | Re: init_sequence spill to hash table |
Дата | |
Msg-id | 20131114141210.GE25959@alap2.anarazel.de обсуждение исходный текст |
Ответ на | init_sequence spill to hash table (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: init_sequence spill to hash table
Re: init_sequence spill to hash table |
Список | pgsql-hackers |
Hi, On 2013-11-13 22:55:43 +1300, David Rowley wrote: > Here http://www.postgresql.org/message-id/24278.1352922571@sss.pgh.pa.us there > was some talk about init_sequence being a bottleneck when many sequences > are used in a single backend. > > The attached I think implements what was talked about in the above link > which for me seems to double the speed of a currval() loop over 30000 > sequences. It goes from about 7 seconds to 3.5 on my laptop. I think it'd be a better idea to integrate the sequence caching logic into the relcache. There's a comment about it:* (We can't* rely on the relcache, since it's only, well, a cache, and maydecide to* discard entries.) but that's not really accurate anymore. We have the infrastructure for keeping values across resets and we don't discard entries. Since we already do a relcache lookup for every sequence manipulation (c.f. init_sequence()) relying on it won't increase, but rather decrease the overhead. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: