Re: Memory Alignment in Postgres

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Arthur Silva <arthurprs(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory Alignment in Postgres
Date: 2014-09-10 20:54:15
Message-ID: CA+Tgmob_dNSeYY2EYP-3bivysY4_5T+zCokLWwLm4nuc_rDjAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 10, 2014 at 4:29 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Sep 10, 2014 at 11:43:52AM -0400, Robert Haas wrote:
>> But there are a couple of obvious problems with this idea, too, such as:
>>
>> 1. It's really complicated and a ton of work.
>> 2. It would break pg_upgrade pretty darn badly unless we employed some
>> even-more-complex strategy to mitigate that.
>> 3. The savings might not be enough to justify the effort.
>>
>> It might be interesting for someone to develop a tool measuring the
>> number of bytes of alignment padding we lose per tuple or per page and
>> gather some statistics on it on various databases. That would give us
>> some sense as to the possible savings.
>
> And will we ever implement a logical attribute system so we can reorder
> the stored attribtes to minimize wasted space?

You forgot to attach the patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-09-10 21:09:54 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Robert Haas 2014-09-10 20:53:12 Re: pg_background (and more parallelism infrastructure patches)