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