tablesample test failure with small TOAST_TUPLE_THRESHOLD
Today, I tried compiling with:
-#define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE)
+#define TOAST_TUPLE_THRESHOLD 100Most of the regression tests pass just fine, but the tablesample one
experiences numerous failures. For example:
SELECT t.id FROM test_tablesample AS t TABLESAMPLE SYSTEM (50) REPEATABLE (0);
id
----
! 3
! 4
! 5
! 6
! 7
! 8
! (6 rows)
SELECT id FROM test_tablesample TABLESAMPLE SYSTEM (100.0/11) REPEATABLE (0);
id
--- 5,11 ----
SELECT t.id FROM test_tablesample AS t TABLESAMPLE SYSTEM (50) REPEATABLE (0);
id
----
! (0 rows) SELECT id FROM test_tablesample TABLESAMPLE SYSTEM (100.0/11) REPEATABLE (0);
id
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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 100Most 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Oct 14, 2016 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
For that particular test, I really fail to see how we could make the
output entirely independent of the number of tuples stored per page.
By design, that tablesample method is sensitive to where the page
boundaries are.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers