Re: [PATCHES] Eliminate more detoast copies for packed varlenas
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Eliminate more detoast copies for packed varlenas |
Дата | |
Msg-id | 5324.1192133016@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Eliminate more detoast copies for packed varlenas (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: [PATCHES] Eliminate more detoast copies for packed varlenas
|
Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > For the record I've been doing some more testing and found one place that > could be a problem down the road. I'm not sure why it didn't show up > previously. In selfuncs.c we use VARDATA/VARSIZE on data that is taken from > parser Const nodes and from the histogram arrays without detoasting them. > Currently this is safe as array elements are not packed and parser nodes > contain values read using textin and never stored in a tuple. But down the > road I expect we'll want to pack array element so this code would need to > detoast the elements or prepare to handle packed elements. Hmmm ... I think this should be fixed now, actually. I'm far from convinced that a Const could never contain a toasted datum. Consider constant-folding in the planner --- it just stuffs the result of a function into a Const node. In fact, it seems there's a different risk here: if such a datum were toasted out-of-line, the reference in a cached plan might live longer than the underlying toast-table data. Maybe we need a forcible detoast in evaluate_function(). regards, tom lane
В списке pgsql-hackers по дате отправления: