[Geocoding] Table space settings and storage
Anders Gunnarsson
anders.gunnarsson at appello.com
Fri Feb 13 13:36:05 UTC 2015
Hi,
I'm currently looking over our setup of Noiminatim, since data is growing out of our current storage capacity with high performance.
I noticed the new tablespace settings attached below, which enables the option to partition into fast and slow storage.
Does anyone have experience with this? How much space is used by each type of data for a full planet? What needs to be on fast media and what can go on slower? I guess all indexes need fast media, and maybe some of the data too.
We currently use one master instance, feeding read only slaves which are used for lookup. If I interpret the settings correct it would be possible to use walbouncer to filter out tablespaces only containing data marked with "update only", so that the slave instances only contain lookup data. Is that true?
// tablespace settings
// osm2pgsql caching tables (aka slim mode tables) - update only
@define('CONST_Tablespace_Osm2pgsql_Data', false);
@define('CONST_Tablespace_Osm2pgsql_Index', false);
// osm2pgsql output tables (aka main table) - update only
@define('CONST_Tablespace_Place_Data', false);
@define('CONST_Tablespace_Place_Index', false);
// address computation tables - update only
@define('CONST_Tablespace_Address_Data', false);
@define('CONST_Tablespace_Address_Index', false);
// search tables - needed for lookups
@define('CONST_Tablespace_Search_Data', false);
@define('CONST_Tablespace_Search_Index', false);
// additional data, e.g. TIGER data, type searches - needed for lookups
@define('CONST_Tablespace_Aux_Data', false);
@define('CONST_Tablespace_Aux_Index', false);
Best regards,
--
Anders Gunnarsson
Software Architect
Location: Appello | Göteborg | Sweden
Web: www.appello.com
More information about the Geocoding
mailing list