----- Original message -----
> 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.
Uh, this seems like purely theoretical speculation, which
also ignores the "generic queue" aspect.
In practice, with databases where there is more reads than
writes, the additional queue write seems insignificant.
So I guess it's up to you to bring hard proofs that the
additional writes are problem.
If we already are speculating, I'd guess that writing to
WAL and INSERT-only queue table involves lot less
seeking than writing to actual table.
But feel free to edit the "Goals" section, unless you are
talking about non-transactional queueing, which seems
off-topic here.
--
marko
