Re: Memory Alignment in Postgres

Поиск
Список
Период
Сортировка
От Arthur Silva
Тема Re: Memory Alignment in Postgres
Дата
Msg-id CAO_YK0WkZY1e7Nq6Xj0CkAD3o5iFSDJg198_BC4o4CGjsfztbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory Alignment in Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Memory Alignment in Postgres  ("ktm@rice.edu" <ktm@rice.edu>)
Список pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 11, 2014 at 12:39 PM, Tom Lane <span
dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span>MerlinMoncure <<a href="mailto:mmoncure@gmail.com"
target="_blank">mmoncure@gmail.com</a>>writes:<br /> > Be advised of the difficulties you are going to face
here. Assuming<br /> > for a second there is no reason not to go unaligned on Intel and there<br /> > are
materialbenefits to justify the effort, that doesn't necessarily<br /> > hold for other platforms like arm/power.<br
/><br/></span>Note that on many (most?) non-Intel architectures, unaligned access is<br /> simply not an option.  The
chipsthemselves will throw SIGBUS or<br /> equivalent if you try it.  Some kernels provide signal handlers that<br />
emulatethe unaligned access in software rather than killing the process;<br /> but the performance consequences of
hittingsuch traps more than very<br /> occasionally would be catastrophic. <br /></blockquote><blockquote
class="gmail_quote"style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br /> Even
onIntel, I'd wonder what unaligned accesses do to atomicity<br /> guarantees and suchlike.  This is not a big deal for
rowdata storage,<br /> but we'd have to be careful about it if we were to back off alignment<br /> requirements for
in-memorydata structures such as latches and buffer<br /> headers.<br /><br /> Another fun thing you'd need to deal
withis ensuring that the C structs<br /> we overlay onto catalog data rows still match up with the data layout<br />
rules.<br/><br /> On the whole, I'm pretty darn skeptical that such an effort would repay<br /> itself.  There are lots
ofmore promising things to hack on.<br /><br />                         regards, tom lane<br /></blockquote></div><br
/>IndeedI don't know any other architectures that this would be at an option. So if this ever moves forward it must be
turnedon at compile time for x86-64 only. I wonder how the Mysql handle their rows even on those architectures as their
storageformat is completely packed.<br /><br /></div><div class="gmail_extra">If we just reduced the alignment
requirementswhen laying out columns in the rows and indexes by reducing/removing padding -- typalign, it'd be enough
gainin my (humble) opinion.<br /><br /></div><div class="gmail_extra">If you think alignment is not an issue you can
seesaving everywhere, which is kinda insane...<br /></div><div class="gmail_extra"><br />I'm unsure how this equates in
patchcomplexity, but judging by the reactions so far I'm assuming a lot.<br /><br /></div></div> 

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

Предыдущее
От: Alexey Klyukin
Дата:
Сообщение: Re: implement subject alternative names support for SSL connections
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: proposal (9.5) : psql unicode border line styles