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.....