Re: Seq Scan

Поиск
Список
Период
Сортировка
От Kevin Hunter
Тема Re: Seq Scan
Дата
Msg-id 7C2BC37D-FC72-4EEA-84B2-D056AE4473B8@earlham.edu
обсуждение исходный текст
Ответ на Re: Seq Scan  ("Tyler Durden" <tylersticky@gmail.com>)
Ответы Re: Seq Scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
of the conversation.
breaks the flow
because it
toppost
Please don't

At 1:17p -0400 on 01 Jun 2007, Tyler Durden wrote:
> Yes,  either case happens the same.
> I'm come recently from MySQL and it works in a different way.
> I find strange that a simple SELECT COUNT(...) is so slow with only
> 700 000 records.
> Has been a nightmare optimizing this tables/queries.
> Sorry about this silly question, but I'm new to Posgresql.

The much more knowledgable will correct me, but the abbr. version is
that it is for data integrity and correctness reasons and the
inherent way in which the MVCC model works.  If it's any condolence,
I believe that Oracle also suffers with this particular query, but I
haven't seen any benchmarks to prove that (I think because Oracle
expressly forbids benchmarks and comparisons in their license, but
don't quote me on that).

For a complete discussion, go this page and look for the thread with
the subject 'Performance of count(*)'

http://archives.postgresql.org/pgsql-performance/2007-03/threads.php

I believe that may help.

Kevin

В списке pgsql-general по дате отправления:

Предыдущее
От: Ron Johnson
Дата:
Сообщение: Continuous PITR (was Re: multimaster)
Следующее
От: "Alexander Staubo"
Дата:
Сообщение: Re: Slightly OT.