From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Avoid creation of the free space map for small tables |
Date: | 2019-02-22 02:59:27 |
Message-ID: | CAA4eK1LOOY9PDvA0DX50N=bFZ9=8oe_MaRGbKVO7oUYj-eVNSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 22, 2019 at 1:57 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> I think this test is going to break on nonstandard block sizes. While
> we don't promise that all tests work on such installs (particularly
> planner ones),
>
The reason for not pushing much on making the test pass for
nonstandard block sizes is that when I tried existing tests, there
were already some failures. For example, see the failures in the
attached regression diff files (for block_size as 16K and 32K
respectively). I saw those failures during the previous
investigation, the situation on HEAD might or might not be exactly the
same. Whereas I see the value in trying to make sure that tests pass
for nonstandard block sizes, but that doesn't seem to be followed for
all the tests.
> it seems fairly easy to cope with this one -- just use a
> record size expressed as a fraction of current_setting('block_size').
> So instead of "1024" you'd write current_setting('block_size') / 8.
> And then display the relation size in terms of pages, not bytes, so
> divide pg_relation_size by block size.
>
The idea sounds good. John, would you like to give it a try?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
regression.16.diffs | application/octet-stream | 2.6 KB |
regression.32.diffs | application/octet-stream | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-02-22 03:58:16 | Unified security key managment |
Previous Message | Tsunakawa, Takayuki | 2019-02-22 02:38:56 | RE: reloption to prevent VACUUM from truncating empty pages at the end of relation |