By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,178 Members | 987 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,178 IT Pros & Developers. It's quick & easy.

What does count(*) count?

P: n/a
Hi all,
I tried to dump out a single table and just for a verification I counted the
number of 'INERT INTO' rows.
I found that count(*) results less rows than grep.
*******************

Csaba@compaq ~
$ pg_dump -d -t t_stockchanges alumil6 > sc.dump

*******************

alumil6=# select count(*) from t_stockchanges ;
count
-------
9816
(1 row)

*******************

Csaba@compaq ~
$ cat sc.dump | grep 'INSERT INTO' | wc -l
4908

*******************
What can be the reason of it?

Thx,

-- Csaba
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
=?iso-8859-2?Q?Egy=FCd_Csaba?= <cs*****@vnet.hu> writes:
I found that count(*) results less rows than grep.


That's a tad hard to believe. I'm suspecting pilot error of some sort.

Perhaps you have more than one table named t_stockchanges (in different
databases or schemas) and you weren't looking at the same one in both
cases?

Another possibility is that t_stockchanges has child table(s). Your
SELECT would count rows in the child tables, but I don't think that
pg_dump -t would dump them.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #2

P: n/a
Hi Tom,
Another possibility is that t_stockchanges has child table(s). Your
SELECT would count rows in the child tables, but I don't think that
That's the case. I tried to copy the content of t_stockchanges table into a
temp table.
Being very lazy:) I created the temp table using create table... inhetit
from ... command instead of creating it independently. I haven't read the
manual carefuly enough regarding inherit clause.
pg_dump -t would dump them.

No, pg_dump doesn't dump them - this was what I found strange.

I suppose this behavior disappears if I drop both table and reload the
t_stockchanges from the dump.

Thank you All.

Bye,
-- Csaba
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.