Re: Freezing without write I/O

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Freezing without write I/O
Date: 2013-06-01 03:32:22
Message-ID: CA+TgmobbTOfzj=gf_Senvy6R8_yWrcBfn0dtsg-rfSZDA6LA8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 31, 2013 at 1:26 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, May 30, 2013 at 10:04:23PM -0400, Robert Haas wrote:
>> > Hm. Why? If freezing gets notably cheaper I don't really see much need
>> > for keeping that much clog around? If we still run into anti-wraparound
>> > areas, there has to be some major operational problem.
>>
>> That is true, but we have a decent number of customers who do in fact
>> have such problems. I think that's only going to get more common. As
>> hardware gets faster and PostgreSQL improves, people are going to
>> process more and more transactions in shorter and shorter periods of
>> time. Heikki's benchmark results for the XLOG scaling patch show
>> rates of >80,000 tps. Even at a more modest 10,000 tps, with default
>> settings, you'll do anti-wraparound vacuums of the entire cluster
>> about every 8 hours. That's not fun.
>
> Are you assuming these are all write transactions, hence consuming xids?

Well, there might be read-only transactions as well, but the point is
about how many write transactions there can be. 10,000 tps or more is
not out of the question even today, and progressively higher numbers
are only going to become more and more common.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-06-01 03:42:51 Re: extensible external toast tuple support
Previous Message Robert Haas 2013-06-01 03:30:29 Re: removing PD_ALL_VISIBLE