From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD |
Date: | 2016-10-14 17:50:07 |
Message-ID: | CA+TgmoZOdZzf7W8hvTYDVJRS16veP0niERnP+nm01HCWKDe69A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 14, 2016 at 9:51 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Today, I tried compiling with:
>> -#define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE)
>> +#define TOAST_TUPLE_THRESHOLD 100
>
>> Most of the regression tests pass just fine, but the tablesample one
>> experiences numerous failures. For example:
>> ...
>> Most of the failures are due to table-sampling that previously
>> returned rows no longer returning any rows. I don't know why that
>> should happen, or whether it's expected.
>
> I think it's probably unsurprising. That test doesn't load very many
> rows, and when you allow them to become toasted, they probably all fit
> into one page. The SYSTEM tablesample method would then return either
> every row, or no row.
>
> Possibly we should be using a less chintzy (ie slower) test there,
> but a change like this would inevitably change the outputs anyway.
OK. So passing the regression tests with different values of
TOAST_TUPLE_THRESHOLD is not a goal? I wasn't sure about that, but if
the answer is "no, that's not a goal", that's fine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-14 17:50:35 | Re: signal handling in plpython |
Previous Message | Robert Haas | 2016-10-14 17:49:08 | Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits. |