From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to avoid transaction ID wrap |
Date: | 2006-06-07 12:57:50 |
Message-ID: | 20060607125750.GB23587@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 07, 2006 at 01:48:50PM +0200, Zdenek Kotala wrote:
> Koichi Suzuki wrote:
> >I've once proposed a patch for 64bit transaction ID, but this causes
> >some overhead to each tuple (XMIN and XMAX). Pgbench with 64bit
> >transaction ID has to pay about a couple of percent of performance.
> >If 64bit transaction ID is a reasonable fix, I've already posted this
> >patch. Anyone can apply this to later versions.
> Did you check performance on 32-bit or 64-bit systems and 64-bit binary
> version of PGSQL? I think that today is not problem to have 64-bit
> architecture and 64-bit ID should increase scalability of Postgres.
I doubt performance is the issue directly. Increasing the size of the
transaction counter would increase the size of narrow tables by maybe
30%. That's 30% more disk space and 30% more memory usage in some
places. Maybe at some point it'll be worth it, but right now I don't
think those commodoties are cheap enough to use like this for fairly
marginal benefits.
Beside, memory bandwidth hasn't grown anywhere enar as fast as memory
space, so it's always a good idea to use as little memory as possible.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-07 13:53:32 | Re: That EXPLAIN ANALYZE patch still needs work |
Previous Message | Simon Riggs | 2006-06-07 12:39:41 | Re: That EXPLAIN ANALYZE patch still needs work |