pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Gregory Stark <stark@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Kim <kim@myemma.com>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] unusual performance for vac following 8.2upgrade
Date: Fri, 12 Jan 2007 12:43:42 +0000
Message-ID: <874pqwwh35.fsf@stark.xeocode.com> (raw)
In-Reply-To: <29730.1168570299@sss.pgh.pa.us>
References: <45A671CD.1050706@myemma.com>
	<27939.1168539652@sss.pgh.pa.us>
	<45A68C74.4080405@myemma.com>
	<28949.1168544710@sss.pgh.pa.us>
	<1168548006.3951.564.camel@silverbirch.site>
	<5414.1168549900@sss.pgh.pa.us>
	<1168557275.3990.49.camel@silverbirch.site>
	<20070112010918.GM10464@alvh.no-ip.org>
	<29730.1168570299@sss.pgh.pa.us>


"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> 3. What about dependencies on user-defined types, functions, etc?
> How will you get things to behave sanely if one backend tries to drop a
> type that some other backend is using in a column of a temp table?  Even
> if you put entries into pg_depend, which would kind of defeat the point
> of not having on-disk catalog entries for temp tables, I don't see how
> the other backend figures out what the referencing object is.

We could just lock the object it depends on. Only really makes sense for very
temporary tables though, not tables a session expects to use for a long series
of transactions.

Another direction to go to address the same problem would be to implement the
standard temporary table concept of a permanent table definition for which
each session gets a different actual set of data which is reset frequently.
Then the meta-data isn't changing frequently.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com



view thread (21+ messages)  latest in thread

Message-ID: <874pqwwh35.fsf@stark.xeocode.com>
Permalink:  ../874pqwwh35.fsf@stark.xeocode.com/
Also on:    postgresql.org/message-id/874pqwwh35.fsf@stark.xeocode.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: stark@enterprisedb.com, tgl@sss.pgh.pa.us, alvherre@commandprompt.com, simon@2ndquadrant.com, kim@myemma.com, pgsql-hackers@postgresql.org
  Subject: Re: [PERFORM] unusual performance for vac following 8.2upgrade
  In-Reply-To: <874pqwwh35.fsf@stark.xeocode.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox