11.10.10 20:46, Craig James ÐÐÐÐÑÐÐ(ÐÐ):
First of all, it's not true. There are plenty of applications that
need an exact answer. Second, even if it is only 1%, that means it's
1% of the queries, not 1% of people. Sooner or later a large fraction
of developers will run into this. It's probably been the most-asked
question I've seen on this forum in the four years I've been here.
It's a real problem, and it needs a real solution.
I know it's a hard problem to solve, but can we stop hinting that
those of us who have this problem are somehow being dense?
BTW: There is a lot of talk about MVCC, but is next solution possible:
1) Create a page information map that for each page in the table will
tell you how may rows are within and if any write (either successful or
not) were done to this page. This even can be two maps to make second
one really small (a bit per page) - so that it could be most time in-memory.
2) When you need to to count(*) or index check - first check if there
were no writes to the page. If not - you can use count information from
page info/index data without going to the page itself
3) Let vacuum clear the bit after frozing all the tuples in the page (am
I using terminology correctly?).
In this case all read-only (archive) data will be this bit off and
index/count(*) will be really fast.
Am I missing something?
Best regards, Vitalii Tymchyshyn.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
