Re: Improving compressibility of WAL files

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Hannu Krosing <hannu(at)krosing(dot)net>, Kyle Cordes <kyle(at)kylecordes(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Improving compressibility of WAL files
Date: 2009-01-10 01:37:34
Message-ID: 20090110013734.GP12094@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

* Greg Smith <gsmith(at)gregsmith(dot)com> [090109 18:39]:

> I was hoping it might fall out of the other work being done in that area,
> given how much that code is still being poked at right now. As Hannu
> pointed out, from a conceptual level you just need to carry along the
> same information that pg_current_xlog_location() returns to the archiver
> on all the paths where a segment might end early.

I was(am) also hoping that somethig falls out of sync-rep that gives me
better PITR backups (better than a small archive_timeout)... That hope
is what made me abandon this patch after the initial feedback.

> Rather than creating a whole new GUC, it might it be possible to turn
> archive_mode into an enum setting: off, on, and cleaned as the modes
> perhaps. That would avoid making a new setting, with the downside that a
> bunch of critical code would look less clear than it does with a boolean.

I'm content to wait and see what falls out of sync-rep stuff...

... for now ...

> I understand the case you've made for why it doesn't matter, and for
> almost every case you're right. The situation it may be vulnerable to is
> where a burst of transactions come in just as the archive timeout expires
> after minimal WAL activity. There I think you can end up with a bunch of
> clients waiting behind an almost full zero fill operation, which pushes
> up the worst-case latency. I've been able to measure the impact of the
> similar case where zero-filling a brand new segment can impact things;
> this would be much less like to happen because the timing would have to
> line up just wrong, but I think it's still possible.

Ya, and it's one of just many of the times PG hits these worst-latency
spikes ;-) GEnerally, it's *very* good... and once in a while, when all
the stars line up correctly, you get these spikes....

But even with these spikes, it's plenty fast enough for the stuff I've
done...

a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrew 2009-01-10 10:14:48 Re: Adding Arabic dictionary for TSearch2.. to_tsvector('arabic'...) doesn't work..
Previous Message Greg Smith 2009-01-09 23:37:11 Re: Improving compressibility of WAL files

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-01-10 03:46:06 Re: Proposal: new border setting in psql
Previous Message Alvaro Herrera 2009-01-10 00:42:09 Re: Updates of SE-PostgreSQL 8.4devel patches (r1389)