Re: SSI SLRU strategy choices
От | Alvaro Herrera |
---|---|
Тема | Re: SSI SLRU strategy choices |
Дата | |
Msg-id | 1293652502-sup-7444@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: SSI SLRU strategy choices ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: SSI SLRU strategy choices
|
Список | pgsql-hackers |
Excerpts from Kevin Grittner's message of mié dic 29 12:20:20 -0300 2010: > http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/slru.h;h=710cca70acd67e03e5f3a255b048a719ae4c4709 > > The way I read this, each segment is (BLCKSZ * > SLRU_PAGES_PER_SEGMENT) long, which is (8kB * 32), or 256kB. The > number of files is limited to 64k because of the 0000 to FFFF > segment file naming. So total space is limited to 16GB. When an > SLRU is used to store xids for random access, that's 4 bytes per > entry, so 2^32 entries are possible, but SLRU code considers it a > problem for the space to become more than half full. With the eight > byte entries I need, there are 2^31 slots for entries, with the > ability to use 2^30 before it becomes half full and SLRU complains. If these limitations become a problem, you can always change them. A couple of zeroes at the start of the pg_clog filenames aren't going to bother anyone, I don't think. Not so sure about your new proposed design's space usage. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: