Re: XID wraparound and busy databases

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XID wraparound and busy databases
Date: 2007-08-16 19:02:23
Message-ID: 200708161902.l7GJ2Nk04441@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO:

* Reduce XID consumption of read-only queries

http://archives.postgresql.org/pgsql-hackers/2007-08/msg00516.php

---------------------------------------------------------------------------

Florian G. Pflug wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >> Is enlarging the xid field something we should consider for 8.4?
> >
> > No. We just got the tuple header down to 24 bytes, we are not going
> > to give that back and then some.
> >
> > If you are processing 6K transactions per second, you can afford to
> > vacuum every couple days... and probably need to vacuum much more often
> > than that anyway, to avoid table bloat.
> >
> > Possibly your respondent should think about trying to do more than one
> > thing per transaction?
>
> I'm wondering how many of those 6k xacts/second are actually modifying
> data. If a large percentage of those are readonly queries, than the need
> for vacuuming could be reduced if postgres assigned an xid only if that
> xid really hits the disk. Otherwise (for purely select-type queries) it
> could use some special xid value.
>
> This is what I'm doing in my Readonly-Queries-On-PITR-Slave patch.
>
> greetings, Florian Pflug

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2007-08-16 19:04:40 Re: Another idea for index-only scans
Previous Message Oleg Bartunov 2007-08-16 18:57:15 Re: building gist index on int[] field is terrible slow. Is it bug?