Thread: oddly high cost but low actual_time (but not in slony replicants)

Only 19 rows in the table.....

explain analyze select * from table_a;
"Seq Scan on table_a  (cost=100000000.00..100000001.02 rows=19
width=103) (actual time=0.007..0.012 rows=19 loops=1)"
"Total runtime: 0.040 ms"

If I run the same query on the same table in a different database that I
pg_restored from a recent dump...same results

"Seq Scan on table_a  (cost=100000000.00..100000001.02 rows=20
width=135) (actual time=0.009..0.011 rows=20 loops=1)"
"Total runtime: 0.046 ms"

But if I run from a slony replicated node...

"Seq Scan on table_a  (cost=0.00..1.20 rows=20 width=103)"

Weird......

No indexes on the table except the primary key (bigserial)...

Not that it has any impact but wherever I get the high cost it is
running on Solaris with the database on a zfs mounted SAN
"PostgreSQL 8.2.4 on i386-pc-solaris2.10, compiled by GCC gcc (GCC)
3.4.3 (csl-sol210-3_4-branch+sol_rpath)"

Low cost comes from FreeBSD nodes running database locally
"PostgreSQL 8.2.4 on i386-portbld-freebsd6.0, compiled by GCC cc (GCC)
3.4.4 [FreeBSD] 20050518"

It appears that may of my tables exhibit this characteristic...
If, however, I use any REAL indexes, cost is much more 'normal'.....

any ideas?

I'm not really worried...but I was troubleshooting a high-cost query
that led me to this table specifically.....

And yes...I vacuumed...analyzed...vacuum analyzed the table to no avail.....

On Wed, Mar 26, 2008 at 01:23:22PM -0500, Jeff Amiel wrote:
> explain analyze select * from table_a;
> "Seq Scan on table_a  (cost=100000000.00..100000001.02 rows=19
> width=103) (actual time=0.007..0.012 rows=19 loops=1)"
> "Total runtime: 0.040 ms"
>
> any ideas?

Looks like you've "disabled" seqscans.  Because seqscan is a fallback
method all disabling does is to make it very expensive.  To check:

  SHOW enable_seqscan;

If it's set then have a look in the config file, or maybe reset the
per-role setting using ALTER ROLE[1].


  Sam

 [1] http://www.postgresql.org/docs/current/static/sql-alterrole.html

Sam Mason wrote:
> Looks like you've "disabled" seqscans.
>
>

Sure enough.  Thanks.