From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PROPOSAL: Fast temporary tables |
Date: | 2016-03-01 16:05:54 |
Message-ID: | CAOeZVifFV0whSjAi5D9JeZCSg6O1UiFEkk7zpnhpD8YAJUd=8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 1, 2016 at 9:30 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> writes:
> >> There are applications that create and delete a lot of temporary
> >> tables. Currently PostgreSQL doesn't handle such a use case well.
>
>
> Yeah, I have a really hard time believing this can ever work. There
> are MANY catalog tables potentially involved here - pg_class,
> pg_attribute, pg_attrdef, pg_description, pg_trigger, ... and loads
> more - and they all can have OID references to each other. If you
> create a bunch of fake relcache and syscache entries, you're going to
> need to give them OIDs, but where will those OIDs come from? What
> guarantees that they aren't in use, or won't be used later while your
> temporary object still exists? I think making this work would make
> parallel query look like a minor feature.
>
>
Fair point, that means inventing a whole new OID generation structure..
--
Regards,
Atri
*l'apprenant*
From | Date | Subject | |
---|---|---|---|
Next Message | Roma Sokolov | 2016-03-01 16:08:46 | Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator |
Previous Message | Robert Haas | 2016-03-01 16:03:50 | Re: The plan for FDW-based sharding |