From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron <ronljohnsonjr(at)gmail(dot)com> |
Cc: | PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Do table-level CHECK constraints affect the query optimizer? |
Date: | 2021-06-29 16:42:56 |
Message-ID: | 449566.1624984976@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ron <ronljohnsonjr(at)gmail(dot)com> writes:
> On 6/29/21 10:41 AM, Michael Lewis wrote:
>> What's an example query that uses indexes on test and does not on live?
> SELECT COUNT(*) FROM sep_info_report_extract;
> On prod, there's a list of "Parallel Seq Scan on xxxx_partname" records in
> the EXPLAIN output, while the test system has a list of "Parallel Index Only
> Scan using ..._idx" records.
It'd be worth checking pg_class.relallvisible page counts for the
partitions on both systems. If an IOS is possible, the main thing
that might push the planner to do a seqscan instead is if it thinks
that too little of the table is all-visible, which would tend to
inflate the index-only scan towards the same cost as a regular index
scan (which'll almost always be considered slower than seqscan).
If there's a significant difference in relallvisible fractions, that
would point to something different in your VACUUM housekeeping on
the two systems.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-06-29 16:49:45 | Re: Have I found an interval arithmetic bug? |
Previous Message | Michael Lewis | 2021-06-29 16:21:54 | Re: Do table-level CHECK constraints affect the query optimizer? |