2011/5/25 Alvaro Herrera <alvhe...@commandprompt.com>: > Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011: >> Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> > I don't know what client-side code might be looking at >> > relpages/reltuples. >> >> I know that I find reltuples useful for getting an "accurate enough" >> sense of rows in a table (or set of tables) without resorting to >> count(*). I'd be OK with any two of pages, tuples, and density; but >> dropping to one would make databases harder to manage, IMV. >> >> Personally, I don't have much code that uses those columns; >> eliminating an existing column wouldn't involve much pain for me as >> long as it could still be derived. > > Well, we only actually need to store one number, because you can figure > out a much more precise number-of-pages figure with pg_relation_size() > divided by configured page size. > > (We feel free to hack around catalogs in other places, and we regularly > break pgAdmin and the like when we drop columns -- people just live with > it and update their tools. I don't think it's such a big deal in this > particular case.)
I may miss something but we need relation size in costsize.c even if we have a reldensity (or we need a reltuples). Else what values should be used to estimate the relation size ? (pg_relation_size() goes down to kernel/fs to ask the stat.st_size, is it really what we want?) > > -- > Álvaro Herrera <alvhe...@commandprompt.com> > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
