Re: Variable length varlena headers redux
От | Bruce Momjian |
---|---|
Тема | Re: Variable length varlena headers redux |
Дата | |
Msg-id | 200702131619.l1DGJIA00442@momjian.us обсуждение исходный текст |
Ответ на | Re: Variable length varlena headers redux (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Variable length varlena headers redux
|
Список | pgsql-hackers |
Greg Stark wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > > So (nigh) every tuple will get deformed and reformed once before it goes to > > > disk? Currently the toast code doesn't even look at a tuple if it's small > > > enough, but in this case we would want it to fire even on very narrow rows. > > > > I'd be inclined to put the intelligence into heap_form_tuple and thereby > > avoid getting the TOAST code involved unless there are wide fields to > > deal with. > > And have heap_deform_tuple / heap_getattr palloc and memcpy the the datum on > the way out? Or wait until detoast time and then do it? > > If we do it on the way out of the heaptuple then we could have a rule that > headers are always compressed in a tuple and always uncompressed out of a > tuple. > > But I'm surprised, I had the impression that you were reluctant to consider > memcpying all the data all the time. Uh, if the macros can read 1 and 4-byte headers, why do we need to allocate memory for them? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: