Re: Duplicate WHERE condition changes performance and plan

Поиск
Список
Период
Сортировка
От singh400@gmail.com
Тема Re: Duplicate WHERE condition changes performance and plan
Дата
Msg-id CAOtbvRKvDmsN0NTrerWmbpSf-0EcQxbMVOB2mLJrOJWS4ObHAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Duplicate WHERE condition changes performance and plan  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Duplicate WHERE condition changes performance and plan
Список pgsql-performance
> If you're using SSD storage, or if the DB is small compared with shared_buffers or RAM, then random_page_cost should
becloser to seq_page_cost.
 

I don't *think* we are using SSDs  but I'll need to confirm that though.

> How large are the indexes? problem_id_idx1 ?

Using the query from here:
https://wiki.postgresql.org/wiki/Index_Maintenance#Index_size.2Fusage_statistics
Output here: https://gist.github.com/indy-singh/e33eabe5cc937043c93b42a8783b3bfb

I've setup a repo here where it is possible to reproduce the weird
behaviour I'm getting:-

https://github.com/indy-singh/postgres-duplicate-where-conditon

That contains the data (amended to remove any private information) as
well as the statements need to recreate tables, indices, and
constraints,

I think after some trial and error this is something to do with the
size of the table and statistics. I've been trying to put together a
Short, Self Contained, Correct example (http://sscce.org/) and the
problem only appears when fill problem_instance.message with junk, but
I have to do it in two steps as outlined in the README in repo.

Indy



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

Предыдущее
От: Arcadio Ortega Reinoso
Дата:
Сообщение: Re: PostgreSQL does not choose my indexes well
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: PostgreSQL does not choose my indexes well