Postgres Pro
Downloads
Home   >   mailing lists

Thread: PostgreSQL opens all the indexes of a relation for every Query during Planning Time?

PostgreSQL opens all the indexes of a relation for every Query during Planning Time?

From
Meenatchi Sandanam
Date:
On checking PostgreSQL code, we see it opens all indexes of a relation for every query planning time as in the attachment. If that is the case, it might lead to Performance degradation for relations with many indexes. Is there any other better way to handle this like Scanning/Opening only the indexes related to columns specified in the query?

Attachment

Re: PostgreSQL opens all the indexes of a relation for every Queryduring Planning Time?

From
Jason Petersen
Date:
On Mar 15, 2018, at 4:18 AM, Meenatchi Sandanam <meen.opm@gmail.com> wrote:

On checking PostgreSQL code, we see it opens all indexes of a relation for every query planning time as in the attachment. If that is the case, it might lead to Performance degradation for relations with many indexes. Is there any other better way to handle this like Scanning/Opening only the indexes related to columns specified in the query?

I’d think you’d need a pretty clear profiling run that points to this as a hot spot before deciding to optimize it. Do you have a query where this is the case?

--
Jason Petersen
Software Engineer | Citus Data
303.736.9255

Re: PostgreSQL opens all the indexes of a relation for every Queryduring Planning Time?

From
Meenatchi Sandanam
Date:

On Fri, Mar 16, 2018 at 10:48 PM, Jason Petersen <jason@citusdata.com> wrote:
On Mar 15, 2018, at 4:18 AM, Meenatchi Sandanam <meen.opm@gmail.com> wrote:

On checking PostgreSQL code, we see it opens all indexes of a relation for every query planning time as in the attachment. If that is the case, it might lead to Performance degradation for relations with many indexes. Is there any other better way to handle this like Scanning/Opening only the indexes related to columns specified in the query?

I’d think you’d need a pretty clear profiling run that points to this as a hot spot before deciding to optimize it. Do you have a query where this is the case?

--
Jason Petersen
Software Engineer | Citus Data
303.736.9255