Re: changeset generation v5-01 - Patches & git tree - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: changeset generation v5-01 - Patches & git tree
Date
Msg-id 20130628155215.GV3757@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: changeset generation v5-01 - Patches & git tree  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera escribió:

> An INSERT wal record is:
> 
> typedef struct xl_heap_insert
> {
>     xl_heaptid    target;            /* inserted tuple id */
>     bool        all_visible_cleared;    /* PD_ALL_VISIBLE was cleared */
>     /* xl_heap_header & TUPLE DATA FOLLOWS AT END OF STRUCT */
> } xl_heap_insert;

Oops.  xl_heaptid is not 6 bytes, but instead:

typedef struct xl_heaptid
{RelFileNode node;ItemPointerData tid;
} xl_heaptid;

typedef struct RelFileNode
{Oid            spcNode;Oid            dbNode;Oid            relNode;
} RelFileNode;        /* 12 bytes */

typedef struct ItemPointerData
{BlockIdData ip_blkid;OffsetNumber ip_posid;
};            /* 6 bytes */

typedef struct BlockIdData
{uint16        bi_hi;uint16        bi_lo;
} BlockIdData;    /* 4 bytes */

typedef uint16 OffsetNumber;

There's purposely no alignment padding anywhere, so xl_heaptid totals 22 bytes.


Therefore,

> So the fixed part is just 22 bytes + 5 bytes; tuple data follows that.
> So adding four more bytes could indeed be significant (but by how much,
> depends on the size of the tuple data).

4 extra bytes on top of 27 is 14% of added overhead (considering only
the xlog header.)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Review: query result history in psql
Next
From: Robert Haas
Date:
Subject: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls