Re: Question regarding the database page layout.
От | Ryan Bradetich |
---|---|
Тема | Re: Question regarding the database page layout. |
Дата | |
Msg-id | e739902b0809021451j2c99c7a4h5991663278e7450@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question regarding the database page layout. (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
Hello Greg, On Tue, Sep 2, 2008 at 9:54 AM, Gregory Stark <stark@enterprisedb.com> wrote: > "Ryan Bradetich" <rbradetich@gmail.com> writes: > The structure on the page is to have a bunch of tuples stored one after the > other. Each tuple is maxaligned after the previous (actually before the > previous since they start from the end but we'll ignore that -- the point is > that they all *start* at a maxaligned position on the page). > > Within each tuple there's a header which is 23 bytes long. Then an optional > null bitmap. In the header is t_hoff which points to the first byte of actual > data -- effectively specifying the length of the null bitmap. t_hoff is > maxaligned as well. Thanks for your persistence in explaining this issue to me. I think I am starting to understand the issues now and I appreciate the help. I think I see the error in my thinking. You and Tom are saying the tuple is MAXALIGN on the page as well. My assumption was that since t_hoff had to be MAXALIGN, the tuple on the page was being MAXALIGN by default. If I was able to INTALIGNt_hoff then the tuple on the page would be free to be INTALIGN as well. Tom gave me the next place to go look later tonight (PageAddItem). > So by intaligning t_hoff you're adjusting where the data within the tuple fits > by making the null bitmap 4 bytes shorter. That seems worth a few cycles but > isn't going to affect every table. It'll only affect tables that have a null > bitmap between 2-5 bytes (mod 8), ie, with 9-40 fields at least one of which > is null. Tables with 9 fields are likely to be relatively wide which means > saving 4 bytes isn't that much of a gain percentagewise. (Though they might be > mostly null....) > > The other 4 bytes you could save is by packing the whole tuples themselves > more closely on the page. That happens when the item pointer is added and > pointed to the tuple. To do that heap_form_tuple would have to return data > back to the caller about the alignment needed to whomever is going to copy it > into the page. AFAICS that could be done in the HeapTuple structure itself > rather than in the tuple though which doesn't seem so bad. Tom may be seeing > something I'm not though. > > Incidentally, can't you set the alignment during the compute_data_size() call > instead of doing an extra pass through the attributes? Probably doesn't change > the cost though. Actually I did not do an extra pass through the attributes. I added the check in an existing pass through the attributes. I did look at adding this check to the heap_compute_data_size(), but took the easy path to see if my patch worked. I will update my patch to do the alignment check in heap_compute_data_size(). Thanks! - Ryan
В списке pgsql-hackers по дате отправления: