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 


_______________________________________________
Geocoding mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/geocoding

Reply via email to