Re: Duplicate WHERE condition changes performance and plan - Mailing list pgsql-performance

From singh400@gmail.com
Subject Re: Duplicate WHERE condition changes performance and plan
Date
Msg-id CAOtbvRKvDmsN0NTrerWmbpSf-0EcQxbMVOB2mLJrOJWS4ObHAQ@mail.gmail.com
Whole thread Raw
In response to Re: Duplicate WHERE condition changes performance and plan  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Duplicate WHERE condition changes performance and plan
List 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 by date:

Previous
From: Arcadio Ortega Reinoso
Date:
Subject: Re: PostgreSQL does not choose my indexes well
Next
From: Jeff Janes
Date:
Subject: Re: PostgreSQL does not choose my indexes well