Jan, Marko, Simon,
I'm concerned that doing anything about the write overhead issue was
discarded almost immediately in this discussion. This is not a trivial
issue for performance; it means that each row which is being tracked by
the GDQ needs to be written to disk a minimum of 4 times (once to WAL,
once to table, once to WAL for queue, once to queue). That's at least
one time too many, and effectively doubles the load on the master server.
This is particularly unacceptable overhead for systems where users are
not that interested in retaining the queue after an unexpected shutdown.
Surely there's some way around this? Some kind of special
fsync-on-write table, for example? The access pattern to a queue is
quite specialized.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com