On Tue, Mar 1, 2016 at 9:30 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Aleksander Alekseev <a.aleks...@postgrespro.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*
