Re: [HACKERS] generic LONG VARLENA
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] generic LONG VARLENA |
Дата | |
Msg-id | 199912130433.XAA15570@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] generic LONG VARLENA (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] generic LONG VARLENA
(Bruce Momjian <pgman@candle.pha.pa.us>)
|
Список | pgsql-hackers |
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> If we are going to do this, we ought also think about solving the > >> generic memory-leakage problem at the same time. No point in having > >> to revisit all the same code later to deal with that issue. > > > I have a good fix for this. My patch suggested the varlena routine > > pfree the pointer returned from expand_long(). No need for that. With > > an LRU cache, we can have the cache itself free the old values. > > Oooh, that's a thought. Sort of like applying TupleTableSlot to > individual datum values. > > > There aren't any cases where the varlena access routines access more > > than two varlena values at the same time. > > Huh? The standard operators on varlena types access at least three (two > inputs and a result), and multi-argument functions could access more. > Also think about functions written in PLs: they could invoke a large > amount of computation, and would still expect to be able to access their > original input arguments. > > I'd feel more comfortable with explicit reference counting. Perhaps > we could make an exception for function return values: the cache > guarantees to hold onto a function return value for a little while > even though no one is holding a refcount on it at the instant it's > returned. Functions (including PL functions) that want to access > varlena values across any significant amount of computation would > have to bump the refcount on those values somehow. I just checked the code, and I don't see any places where a varlena is returned that isn't palloc'ed inside the function, so the cache memory never makes it out of the routines. However, I see any reference to VARDATA could be a problem because it assume the data is there, and not in the long* relations. I could probably figure out which ones need expanding. They are mostly system table accesses. The others go through adt or are output to the user. > > > I am excited about the long data type. This is _the_ way to do long > > data types. Have any of the commercial databases figured out this way > > to do it. I can't imagine a better system. > > I think we are working on some really cool ideas here. But I *don't* > think we have a solid enough hold on all the details that we can expect > to implement it and ship it out one-two-three. Thus my feeling that > this is for 7.1 not 7.0... We have gotten pretty far in two days. This long tuple stuff is not as difficult as foreign key because I can actually figure out what is happening with the long types, while foreign key is a complete mystery to me. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: