Michael Paquier <mich...@paquier.xyz> writes:
> While browsing the buildfarm failures, I have found this problem on
> anole for the test temp:
> ...
> This could be solved just with an ORDER BY as per the attached. Any
> objections?
There's no reason to expect stability of row order in pg_class, so
in principle this is a reasonable fix, but I kind of wonder why it's
necessary. The plan I get for this query is
regression=# explain select relname from pg_class where relname like
'temp_parted_oncommit_test%';
QUERY PLAN
-------------------------------------------------------------------------------------------------
Index Only Scan using pg_class_relname_nsp_index on pg_class (cost=0.28..4.30
rows=1 width=64)
Index Cond: ((relname >= 'temp'::text) AND (relname < 'temq'::text))
Filter: (relname ~~ 'temp_parted_oncommit_test%'::text)
(3 rows)
which ought to deliver sorted rows natively. Adding ORDER BY doesn't
change this plan one bit. So what actually happened on anole to cause
a non-sorted result?
Not objecting to the patch, exactly, just feeling like there's
more here than meets the eye. Not quite sure if it's worth
investigating closer, or what we'd even need to do to do so.
BTW, I realize from looking at the plan that LIKE is interpreting the
underscores as wildcards. Maybe it's worth s/_/\_/ while you're
at it.
regards, tom lane
