|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Nikolay Shaplov <dhyan(at)nataraj(dot)su>|
|Cc:||pgsql-hackers(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Subject:||Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-02-22 19:48:46 +0300, Nikolay Shaplov wrote:
> This is part or my bigger patch https://www.postgresql.org/message-id/flat/2146419(dot)veIEZdk4E4(at)x200m#2146419(dot)veIEZdk4E4@x200m we've decided to
> commit by smaller parts.
I've not read that thread. Is this supposed to be a first step towards
> So for example if you set custom fillfactor value for some index, then it will
> lead to allocating 84 bytes of memory (sizeof StdRdOptions on i386) and only 8
> bytes will be actually used (varlena header and fillfactor value). 74 bytes is
> not much, but allocating them for each index for no particular reason is bad
> idea, as I think.
I'm not sure this is a particularly strong motivator though? Does the
patch have a goal besides saving a few bytes?
> Moreover when I wrote my big reloption refactoring patch, I came to "one
> reloption kind - one binary representation" philosophy. It allows to write
> code with more logic in it.
I have no idea what this means?
Are you aiming this for v11 or v12?
|Next Message||Andres Freund||2018-03-02 00:19:20||Re: Rewrite of pg_dump TAP tests|
|Previous Message||David Steele||2018-03-02 00:12:25||Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug|