Re: cluster test - Mailing list pgsql-patches

From Tom Lane
Subject Re: cluster test
Date
Msg-id 10937.1180109383@sss.pgh.pa.us
Whole thread Raw
In response to Re: cluster test  (Joachim Wieland <joe@mcknight.de>)
Responses Re: cluster test  (Gregory Stark <stark@enterprisedb.com>)
Re: cluster test  (Joachim Wieland <joe@mcknight.de>)
List pgsql-patches
Joachim Wieland <joe@mcknight.de> writes:
> EXPLAIN SELECT conname FROM pg_constraint WHERE conrelid = 'clstr_tst'::regclass;
>                                             QUERY PLAN
> ---------------------------------------------------------------------------------------------------
>  Index Scan using pg_constraint_conrelid_index on pg_constraint (cost=0.00..8.27 rows=1 width=64)
>    Index Cond: (conrelid = 170982::oid)
> (2 rows)

Actually, can the locale idea --- it looks like a plan-instability
thing.  On my machines I get results like this:

regression=# explain SELECT conname FROM pg_constraint WHERE conrelid = 'clstr_tst'::regclass;
                          QUERY PLAN
--------------------------------------------------------------
 Seq Scan on pg_constraint  (cost=0.00..7.35 rows=1 width=64)
   Filter: (conrelid = 28856::oid)
(2 rows)

regression=# SELECT conname FROM pg_constraint WHERE conrelid = 'clstr_tst'::regclass;
    conname
----------------
 clstr_tst_pkey
 clstr_tst_con
(2 rows)

regression=# set enable_seqscan TO 0;
SET
regression=# explain SELECT conname FROM pg_constraint WHERE conrelid = 'clstr_tst'::regclass;
                                            QUERY PLAN
---------------------------------------------------------------------------------------------------
 Index Scan using pg_constraint_conrelid_index on pg_constraint  (cost=0.00..8.27 rows=1 width=64)
   Index Cond: (conrelid = 28856::oid)
(2 rows)

regression=# SELECT conname FROM pg_constraint WHERE conrelid = 'clstr_tst'::regclass;
    conname
----------------
 clstr_tst_con
 clstr_tst_pkey
(2 rows)

This is in the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
"expected" results are what you get from a seqscan.  Would you force a
seqscan and see what EXPLAIN shows as the cost on your machine?

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: cluster test
Next
From: Gregory Stark
Date:
Subject: Re: cluster test