Re: [QUESTIONS] Re: [HACKERS] text should be a blob field
От | Peter T Mount |
---|---|
Тема | Re: [QUESTIONS] Re: [HACKERS] text should be a blob field |
Дата | |
Msg-id | Pine.LNX.3.95.980304183934.1762A-100000@maidast обсуждение исходный текст |
Ответ на | Re: [QUESTIONS] Re: [HACKERS] text should be a blob field (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
On Wed, 4 Mar 1998, Bruce Momjian wrote: > > 1. Is there a call made by the backend to each datatype when a row is > > deleted? I can't see one. > > Well, you could have a RULE that deletes the large object at row > deletion time. As I haven't yet played with Rules & Triggers, and now we have 6.3 out of the way, I'm going to start. > However, if two rows point to the same large object, the first one > deleting it would delete the large object for the other. The only > solution to this is to have a separate large object table, and use > reference counts so only the last user of the object deletes it. Ah, in this case, there would be a single large object per column/row. If the row is deleted, then so will the blob. > > 2. When we update a row, we don't want the overhead of copying a very > > large blob when a row is first copied, then the original deleted, etc. > > Again, a deletion-only rule, but if the update the row and change the > large object, you would have to delete the old stuff. That's true. > Seems very messy to me. Perhaps put all the large objects in a table, > and have a process clean up all the unreferenced large objects. I think that would be a last resort thing to use. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
В списке pgsql-hackers по дате отправления: