Joel Jacobson <joel@trustly.com> writes:
> On Mon, Jun 29, 2015 at 11:14 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
> wrote:
>> What might be interesting is setting things up so the collector simply
>> inserted into history tables every X seconds and then had a separate
>> process to prune that data. The big problem with that is I see no way for
>> that to easily allow access to real-time data (which is certainly necessary
>> sometimes)
> I think the idea sounds promising. If near real-time data is required, we
> could just update once every second, which should be often enough for
> everybody.
I'd bet a good lunch that performance will be absolutely disastrous.
Even with unlogged tables, the vacuuming cost would be intolerable. Why
would we insist on pushing the envelope in what's known to be Postgres'
weakest area performance-wise?
> Each backend process could then simply INSERT the stats for each txn that
> committed/rollbacked into an UNLOGGED table,
... and if its transaction failed, how would it do that?
Regular tables are *not* what we want here, either from a semantics or
a performance standpoint.
regards, tom lane