Skip site navigation (1) Skip section navigation (2)

Re: cluster test

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: cluster test
Date: 2007-05-25 16:09:43
Message-ID: 10937.1180109383@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Joachim Wieland <joe(at)mcknight(dot)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

In response to

Responses

pgsql-patches by date

Next:From: Gregory StarkDate: 2007-05-25 16:55:10
Subject: Re: cluster test
Previous:From: Tom LaneDate: 2007-05-25 16:00:21
Subject: Re: cluster test

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group