Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4
Дата
Msg-id
28396.1224509546@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Sergey Konoplev" <gray.ru@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Tom Lane <tgl@sss.pgh.pa.us>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Sergey Konoplev" <gray.ru@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Sergey Konoplev" <gray.ru@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Tom Lane <tgl@sss.pgh.pa.us>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Teodor Sigaev <teodor@sigaev.ru>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Teodor Sigaev <teodor@sigaev.ru>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Tom Lane <tgl@sss.pgh.pa.us>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Sergey Konoplev" <gray.ru@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Sergey Konoplev" <gray.ru@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Teodor Sigaev <teodor@sigaev.ru>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Teodor Sigaev <teodor@sigaev.ru>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 "Laurent Wandrebeck" <l.wandrebeck@gmail.com>
Re: index scan leads to result that is different from sec scan after upgrading to 8.3.4 Teodor Sigaev <teodor@sigaev.ru>
"Sergey Konoplev"  writes:
> db_online=> select obj_status_did, count(1) from person_online
> where obj_status_did = 1 group by obj_status_did;
>                                                         QUERY PLAN
> -------------------------------------------------------------------------------------------------------------------------
>  GroupAggregate  (cost=0.00..36.37 rows=1 width=2) (actual
> time=1.169..1.170 rows=1 loops=1)
>    ->  Index Scan using i_person_online_test__geo_point on
> person_online_test  (cost=0.00..30.07 rows=1258 width=2) (actual
> time=0.016..0.928 rows=258 loops=1)
>  Total runtime: 1.268 ms
> (3 rows)

Hmm.  So the problem seems to be statable as "a full-index scan on a
GIST index might fail to return all the rows, if the index has been
modified since creation".  Teodor, can you think of anything you
changed recently in that area?

			regards, tom lane
В списке pgsql-general по дате отправления
От: Sergey Konoplev
Дата:
От: Sergey Konoplev
Дата:
FAQ