Re: Implementation of global temporary tables?

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Zhaomo Yang <zhy001(at)cs(dot)ucsd(dot)edu>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Implementation of global temporary tables?
Date: 2015-07-14 22:20:57
Message-ID: 55A58B49.9020206@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/9/15 12:45 AM, Pavel Stehule wrote:
>
> 2015-07-09 7:32 GMT+02:00 Zhaomo Yang <zhy001(at)cs(dot)ucsd(dot)edu
> <mailto:zhy001(at)cs(dot)ucsd(dot)edu>>:
>
> > I am not sure, if it is not useless work.
>
> I don't understand why an implementation taking approach 2.a would
> be useless. As I said, its performance will be no worse than current
> temp tables and it will provide a lot of convenience to users who
> need to create temp tables in every session.
>
>
> Surely it should be step forward. But you will to have to solve lot of
> problems with "duplicated" tables in system catalogue, and still it
> doesn't solve the main problem with temporary tables - the bloating
> catalogue - and related performance degradation.

That being the "main" problem is strictly a matter of opinion based on
your experience. Many people don't have a performance problem today, but
do have to deal with all the pain of handling this manually (as well as
all the limitations that go with that).

If it's easy to fix the bloat problem at the same time as adding GLOBAL
TEMP then great! But there's no reason to reject this just because it
doesn't fix that issue.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-07-15 00:34:53 Re: optimizing vacuum truncation scans
Previous Message Tom Lane 2015-07-14 22:04:00 Re: ctidscan as an example of custom-scan (Re: [v9.5] Custom Plan API)