Re: Select max(foo) and select count(*) optimization
От | Christopher Browne |
---|---|
Тема | Re: Select max(foo) and select count(*) optimization |
Дата | |
Msg-id | m31xqdetnr.fsf@wolfe.cbbrowne.com обсуждение исходный текст |
Ответ на | Select max(foo) and select count(*) optimization (John Siracusa <siracusa@mindspring.com>) |
Ответы |
Re: Select max(foo) and select count(*) optimization
|
Список | pgsql-performance |
Martha Stewart called it a Good Thing when paul@tuckfield.com (Paul Tuckfield) wrote: > Not that I'm offering to do the porgramming mind you, :) but . . > > In the case of select count(*), one optimization is to do a scan of the > primary key, not the table itself, if the table has a primary key. In a > certain commercial, lesser database, this is called an "index fast full > scan". It would be important to scan the index in physical order > (sequential physical IO) and not in key order (random physical IO) The problem is that this "optimization" does not actually work. The index does not contain transaction visibility information, so you have to go to the pages of tuples in order to determine if any given tuple is visible. > I'm guessing the payoff as well as real-world-utility of a max(xxx) > optimization are much higher than a count(*) optimization tho That's probably so. In many cases, approximations, such as page counts, may be good enough, and pray consider, that ("an approximation") is probably all you were getting from the database systems that had an "optimization" to store the count in a counter. -- let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;; http://www3.sympatico.ca/cbbrowne/linuxxian.html "No, you misunderstand. Microsoft asked some hackers how they could make their system secure - the hackers replied "Turn it off.". So they did." -- Anthony Ord
В списке pgsql-performance по дате отправления: