Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD - Mailing list pgsql-hackers

From Robert Haas
Subject Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD
Date
Msg-id CA+TgmoZOdZzf7W8hvTYDVJRS16veP0niERnP+nm01HCWKDe69A@mail.gmail.com
Whole thread Raw
In response to Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tablesample test failure with small TOAST_TUPLE_THRESHOLD  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 14, 2016 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Next
From: Tom Lane
Date:
Subject: Re: signal handling in plpython