[OSM-talk] live rendering

[Martijn van Oosterhout]

On 5/3/07, Frederik Ramm <frederik at remote.org> wrote:
> The more you use triggers, the more you slow down a simple update with
> tasks that are in fact the first step of a rendering process. I still
> maintain it would be a much more solid alternative to invest work in a
> way of keeping a live copy of the data, where you can run triggers to
> your heart's content without delaying changes or insertions of new data
> to the central repository.

Umm, on average the data is going to be read far more often than it's
going to be written so the cost of the trigger is marginal. Certainly
cheaper than doing it each time you render. Also postgres is lock free
(readers don't block writers, writers don't block readers) so there's
no real downside to having the update take a little longer, it doesn't
affect the number of concurrent queries.

> But this is an opinion built from theory, and from having seen
> considerable harm done by triggers in the wrong hands ;-) - I cannot say
> how complicated the required operations will be, and maybe Postgres even
> has a way to execute triggers asynchronously without delaying the
> operation that fired the trigger.

Technically, yes it can. In practice it's usually better to have the
trigger update a table immediatly and have a seperate asyncronous
process handle the hard work. I havn't measured it, but I beleive
having a trigger calculate the bounding box straight away on insert is
cheaper than updating the row again later, not least because you save
a several disk writes and get less wasted disk space.

Yes, triggers can be evil when used poorly, but on postgres they are
usually more efficient than the alternatives.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/