| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 64-bit XIDs again |
| Date: | 2015-07-30 15:12:39 |
| Message-ID: | 55BA3EE7.1050500@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07/30/2015 08:04 AM, Simon Riggs wrote:
> There is a big downside to expanding xmin/xmax to 64 bits: it takes
> space. More space means more memory needed for caching, more memory
> bandwidth, more I/O, etc.
>
>
> My feeling is that the overhead will recede in time. Having a nice,
> simple change to remove old bugs and new would help us be more robust.
>
> But let's measure the overhead before we try to optimize it away.
In field experience would agree with you. The amount of memory people
are arbitrarily throwing at databases now is pretty significant. It is
common to have >64GB of memory. Heck, I run into >128GB all the time and
seeing >192GB is no longer a, "Wow".
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-07-30 15:44:04 | Re: security labels on databases are bad for dump & restore |
| Previous Message | Simon Riggs | 2015-07-30 15:04:27 | Re: 64-bit XIDs again |