Cott Lang <cott(at)internetstaff(dot)com> writes:
> If the number of tuples is sufficiently high, pg reports 'reltuples'
> back in TABLE_STATS_QUERY in scientific notation instead of an integer.
Right, because that column is actually a float4.
> Changing from atoi() to atof() solves the problem completely.
> new_tbl->reltuples =
> atof(PQgetvalue(res, row, PQfnumber(res, "reltuples")));
> new_tbl->relpages =
> atof(PQgetvalue(res, row, PQfnumber(res, "relpages")));
I should think this would break in different ways once reltuples exceeds
INT_MAX. A full fix would require changing new_tbl->reltuples to be
float or double, and coping with any downstream changes that implies.
Also, relpages *is* an integer, though it's best interpreted as an
unsigned one. (Ditto for relid.) Looks like this code is 0-for-3 on
getting the datatypes right :-(
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2004-01-18 03:22:51|
|Subject: Re: User Defined Functions/AM's inherently slow? |
|Previous:||From: Eric Ridge||Date: 2004-01-18 02:25:43|
|Subject: User Defined Functions/AM's inherently slow?|
pgsql-bugs by date
|Next:||From: PostgreSQL Bugs List||Date: 2004-01-18 12:41:56|
|Subject: BUG #1054: inefficient compression of doco html files|
|Previous:||From: Cott Lang||Date: 2004-01-17 23:22:45|
|Subject: Bug in pg_autovacuum ?|