From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-cluster-hackers(at)postgresql(dot)org |
Subject: | Re: GDQ iimplementation |
Date: | 2010-05-17 21:46:13 |
Message-ID: | 4BF1B925.7010809@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-cluster-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2010-05-17 22:52:26 | Re: GDQ iimplementation |
Previous Message | Simon Riggs | 2010-05-17 17:01:22 | Re: BOF at pgCon? |