Re: Performance pb vs SQLServer.

От: Tom Lane
Тема: Re: Performance pb vs SQLServer.
Дата: ,
Msg-id: 14401.1124068725@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Performance pb vs SQLServer.  ("Steinar H. Gunderson")
Ответы: Re: Performance pb vs SQLServer.  ("Steinar H. Gunderson")
Список: pgsql-performance

Скрыть дерево обсуждения

Performance pb vs SQLServer.  (Stéphane COEZ, )
 Re: Performance pb vs SQLServer.  (John Arbash Meinel, )
  Re: Performance pb vs SQLServer.  ("Steinar H. Gunderson", )
   Re: Performance pb vs SQLServer.  (John Arbash Meinel, )
   Re: Performance pb vs SQLServer.  (Tom Lane, )
    Re: Performance pb vs SQLServer.  ("Steinar H. Gunderson", )
  Re: Performance pb vs SQLServer.  ("Steinar H. Gunderson", )
  Re: Performance pb vs SQLServer.  (Stéphane COEZ, )
 Re: Performance pb vs SQLServer.  (, )
  Re: Performance pb vs SQLServer.  (Stéphane COEZ, )
 Re: Performance pb vs SQLServer.  ("Magnus Hagander", )
  Re: Performance pb vs SQLServer.  (Stéphane COEZ, )
 Re: Performance pb vs SQLServer.  ("Magnus Hagander", )
  Re: Performance pb vs SQLServer.  (Alvaro Herrera <-ip.org>, )
  Re: Performance pb vs SQLServer.  ("Qingqing Zhou", )
   Re: Performance pb vs SQLServer.  (John A Meinel, )

"Steinar H. Gunderson" <> writes:
> To me, it looks like he'll get 88 rows, not 3.2M. Surely we must be able to
> do something better than a full sequential scan in this case?

Not really.  There's been some speculation about implementing index
"skip search" --- once you've verified there's at least one visible
row of a given index value, tell the index to skip to the next different
value instead of handing back any of the remaining entries of the
current value.  But it'd be a lot of work and AFAICS not useful for
very many kinds of queries besides this.

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: "Petr Kavan"
Дата:
Сообщение: Re: How many views is ok?
От: "Magnus Hagander"
Дата:
Сообщение: Re: Performance pb vs SQLServer.