Re: Manipulating complex types as non-contiguous structures in-memory

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Manipulating complex types as non-contiguous structures in-memory
Дата
Msg-id 20150514010609.GC9584@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Manipulating complex types as non-contiguous structures in-memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Manipulating complex types as non-contiguous structures in-memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
> >> I still think that going back to defining the second byte as the size
> >> would be better.  Fortunately, since this is only a matter of in-memory
> >> representations, we aren't committed to any particular answer.
> 
> > Requiring sizes to be different still strikes me as a disaster. Or is
> > that not what you're proposing?
> 
> It is, but why would it be a disaster?  We could add StaticAsserts
> verifying that the sizes actually are different.  I doubt that the pad
> space itself could amount to any issue performance-wise, since it would
> only ever exist in transient in-memory tuples, and even that only seldom.

The sizes would be platform dependant. It's also just incredibly ugly to
have to add pad bytes to structures so we can disambiguate them.

Anyway, I think we can live with your & or my proposed additional branch
for now. I can't see either variant being a relevant performance
bottleneck anytime soon.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Manipulating complex types as non-contiguous structures in-memory
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Manipulating complex types as non-contiguous structures in-memory