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. +
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? |