Re: [HACKERS] unusual performance for vac following 8.2upgrade

From: Richard Huxton <dev(at)archonet(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kim <kim(at)myemma(dot)com>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] unusual performance for vac following 8.2upgrade
Date: 2007-01-12 09:06:40
Message-ID: 45A74FA0.8090801@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Can we actually get rid of pg_class entries for temp tables. Maybe
>> creating a "temp pg_class" which would be local to each session? Heck,
>> it doesn't even have to be an actual table -- it just needs to be
>> somewhere from where we can load entries into the relcache.
>
> A few things to think about:
>
> 1. You'll break a whole lotta client-side code if temp tables disappear
> from pg_class.

> 2. How do you keep the OIDs for temp tables (and their associated
> rowtypes) from conflicting with OIDs for real tables?

> 3. What about dependencies on user-defined types, functions, etc?

Is there not some gain from just a "standard" partitioning of pg_class
into: (system-objects, user-objects, temp-objects)? I'd expect them to
form a hierarchy of change+vacuum rates (if you see what I mean).

--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Mair 2007-01-12 09:41:11 Re: [COMMITTERS] pgsql: Stamp major release 8.3.0,
Previous Message Stefan Kaltenbrunner 2007-01-12 08:29:36 Re: [COMMITTERS] pgsql: Stamp major release 8.3.0,

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2007-01-12 09:17:48 Re: Planner statistics, correlations
Previous Message Tobias Brox 2007-01-12 09:05:00 Re: Planner statistics, correlations