DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	b=ZqORC532GMa53bvxtbO8lcoAWAAiL2ZgrhxbLO9sFQxKke1kD7ycDdaPoXYdJfCBMs
	4XBTbRRVtfV01kp/SBPZWqBJ/ZEtb8egxwEfXhLEc6g/YGhSIvbAKADHeHvv6kuC1w50
	xrfwhkhT4G0fyhs9gmlhQCtUAO1Hp8fA2UIxg=
Message-ID: <4CB4149D.8030803@gmail.com>
Date: Tue, 12 Oct 2010 10:56:13 +0300
From: Vitalii Tymchyshyn <tivv00@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Slow count(*) again...
References: <201010091626.18636.neil.whelchel@gmail.com>
	<AANLkTimayTM__hHu9RoiLaNhzfpNY6Vo5y4OkbX_sV=o@mail.gmail.com>
	<4CB34D69.6060108@emolecules.com>
In-Reply-To: <4CB34D69.6060108@emolecules.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.