| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Freeze avoidance of very large table. |
| Date: | 2015-04-23 15:41:25 |
| Message-ID: | 20150423154125.GA31856@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 23, 2015 at 06:24:00PM +0300, Heikki Linnakangas wrote:
> >I've often wondered if there was some way we could consolidate XMIN/XMAX
> >from multiple tuples at the page level; that could be a big win for OLAP
> >environments where most of your tuples belong to a pretty small range of
> >XIDs. In many workloads you could have 80%+ of the tuples in a table
> >having a single inserting XID.
>
> It would be doable for xmin - IIRC someone even posted a patch for
> that years ago - but xmax (and ctid) is difficult. When a tuple is
> inserted, Xmax is basically just a reservation for the value that
> will be put there later. You have no idea what that value is, and
> you can't influence it, and when it's time to delete/update the row,
> you *must* have the space for that xmax. So we can't
> opportunistically use the space for anything else, or compress them
> or anything like that.
Also SELECT FOR UPDATE uses the per-row xmax too.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2015-04-23 15:45:32 | Re: Freeze avoidance of very large table. |
| Previous Message | Petr Jelinek | 2015-04-23 15:39:41 | Re: Freeze avoidance of very large table. |