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: | 3708.959377527@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-26 21:54:44 | Re: Update Performance from 6.5.0 to 6.5.3 to 7.0 |
Previous Message | Travis Bauer | 2000-05-26 21:23:22 | setting permissions on a new table in a trigger |