Skip site navigation (1) Skip section navigation (2)

Re: SSI SLRU strategy choices

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI SLRU strategy choices
Date: 2010-12-29 20:00:26
Message-ID: 1293652502-sup-7444@alvh.no-ip.org (view raw or flat)
Thread:
Lists: 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-12-29 20:01:09
Subject: Re: Extensions, patch v16
Previous:From: Bruce MomjianDate: 2010-12-29 20:00:12
Subject: Re: Extensions, patch v16

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group