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.
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 |
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) |