| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
| Date: | 2016-08-24 05:04:45 |
| Message-ID: | 20160824050445.GA192014@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Claudio Freire wrote:
> After looking at it from a birdseye view, I agree it's conceptually
> complex (reading HeapTupleSatisfiesSelf already makes one dizzy).
>
> But other than that, the implementation seems rather simple. It seems
> to me, if one figures out that it is safe to do so (a-priori, xmin not
> committed, xmax is current transaction), it would simply be a matter
> of chasing the HOT chain root, setting all LP except the first to
> LP_UNUSED and the first one to LP_DEAD.
>
> Of course I may be missing a ton of stuff.
What you seem to be missing is that rows corresponding to temp tables
are not "visible to its own transaction only". The rows are valid
after the transaction is gone; what makes the tables temporary is the
fact that they are in a temporary schema. And what makes them invisible
to one backend is the fact that they are in the temporary schema for
another backend. Not that they are uncommitted.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2016-08-24 05:05:17 | Re: Write Ahead Logging for Hash Indexes |
| Previous Message | Mark Kirkwood | 2016-08-24 05:01:12 | Re: Write Ahead Logging for Hash Indexes |