Re: Bad Query Plans on 10.3 vs 9.6

Поиск
Список
Период
Сортировка
Искать
От
Cory Tucker
Тема
Re: Bad Query Plans on 10.3 vs 9.6
Дата
Msg-id
CAG_=8kBKebY6A+xTmGvM95B3q41xLtGQoJjckV8VzH=L2t_pUw@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Bad Query Plans on 10.3 vs 9.6 Cory Tucker <cory.tucker@gmail.com>
Re: Bad Query Plans on 10.3 vs 9.6 David Rowley <david.rowley@2ndquadrant.com>
Re: Bad Query Plans on 10.3 vs 9.6 Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad Query Plans on 10.3 vs 9.6 Cory Tucker <cory.tucker@gmail.com>
Re: Bad Query Plans on 10.3 vs 9.6 David Rowley <david.rowley@2ndquadrant.com>
Re: Bad Query Plans on 10.3 vs 9.6 Cory Tucker <cory.tucker@gmail.com>
Re: Bad Query Plans on 10.3 vs 9.6 Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad Query Plans on 10.3 vs 9.6 Cory Tucker <cory.tucker@gmail.com>
Each table in your database has an entry in the pg_class table. Something like:

SELECT relallvisible from pg_class where oid = 'build.household'::regclass;

would show you the value, however, I think a problem here is unlikely
since that would just control the likelihood of an index-only-scan vs
an index-scan. You're getting a Seq-scan, which I imagine is going to
be quite a bit more expensive than even an index scan.

relallvisible has a value of 0 for that table on both databases.
В списке pgsql-general по дате отправления
От: David Rowley
Дата:
От: Ravi Krishna
Дата:
Сообщение: Question about AWS Calculator
FAQ