Skip site navigation (1) Skip section navigation (2)

Re: Speed of locating tables?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Speed of locating tables?
Date: 2000-05-26 21:45:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Barry Lind <barry(at)xythos(dot)com> writes:
> This sounds doable.  It would probably also remove the problem I have
> that unlinks of large objects can't be rolled back.

Right, lo_unlink would become something like
	"DELETE FROM pg_largeobjects WHERE loid = NNNN" 
which is perfectly rollbackable.  This would also solve the problem a
number of people have had with accessing thousands of LOs in a single
transaction.  (The lock manager tends to run out of shared memory when
asked to keep track of that many table locks :-(.)

This might also make dump/restore of large objects more manageable,
since you'd just be talking about dumping & restoring the contents of
this one table instead of having to look around to see what LOs exist.

A disadvantage I didn't think of before is that it'd take extra work to
implement access protection of LOs --- we do not have any existing way
of protecting individual rows in a table...

			regards, tom lane

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2000-05-26 21:54:44
Subject: Re: Update Performance from 6.5.0 to 6.5.3 to 7.0
Previous:From: Travis BauerDate: 2000-05-26 21:23:22
Subject: setting permissions on a new table in a trigger

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group