[OSM-dev] Is there a way to use simple schema without hstore

Sarah Hoffmann lonvia at denofr.de
Sun Nov 21 15:43:30 GMT 2010


On Sat, Nov 20, 2010 at 11:52:58AM +1100, Brett Henderson wrote:
> On Fri, Nov 19, 2010 at 10:50 PM, Sarah Hoffmann <lonvia at denofr.de> wrote:
> 
> > On Fri, Nov 19, 2010 at 09:37:33AM +0100, Andreas Kalsch wrote:
> > >> If you're applying diffs to the database you can enhance the
> > >> osmosisUpdate() function (initially empty, but can be customised) to
> > >> keep your separate tags tables up to date during each diff
> > >> application.  You will need to run the
> > >> "pgsql_simple_schema_0.6_action.sql" script against the database so
> > >> that all actions during a diff are logged and can be used by your
> > >> osmosisUpdate function to know which records need to be re-processed.
> > > Is it possible to truncate the actions table for myself so that a
> > > separate script can access the changes?
> >
> > Simply copy away the information from the action table somewhere
> > persistent in the osmosisUpdate function. Works fine.
> >
> > However, +1 from me for an action table that can be truncated manually.
> >
> 
> Is there likely to be a noticeable performance improvement in doing this?

I doubt that. Compared to the entire update task, the overhead of copying
is negligible. It is more a design question. I prefer to keep osmosis and
the scripts for derived tables strictly apart. Doing part of the update
process for derived tables in the osmosisUpdate function intermangles the
two and is very difficult to debug. What was the idea behind osmosisUpdate?
To allow the code to be executed within the same transaction as the changeset
application?

> My preference if the overhead is small would be to add a contrib script to
> Osmosis that installs a non-truncating table that is updated by
> osmosisUpdate, and a customised osmosisUpdate function.  It keeps the pgsql
> tasks simpler if I can do that.

I would have expected that an implementation without update function and a
persistent action table is simpler. Or do you mean, providing both variants
is too complex? In that case, don't worry about it. The current osmosisUpdate
does what I need and writing an apropriate function is simple. I'll just no 
longer think of it as a quick and dirty hack but as the proper way to do 
it. ;)

Sarah



More information about the dev mailing list