Re: missing indexes in indexlist with partitioned tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: missing indexes in indexlist with partitioned tables
Date
Msg-id 32925.1663441201@sss.pgh.pa.us
Whole thread Raw
In response to Re: missing indexes in indexlist with partitioned tables  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: missing indexes in indexlist with partitioned tables
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Sep-16, David Rowley wrote:
>> I kinda disagree with Alvaro's fix in 05fb5d661. I think indexlist is
>> the place to store these details.  That commit added the following
>> comment:
>>
>> /*
>> * Ignore partitioned indexes, since they are not usable for
>> * queries.
>> */
>>
>> But neither are hypothetical indexes either, yet they're added to
>> RelOptInfo.indexlist.
>>
>> I think the patch should be changed so that the existing list is used
>> and we find another fix for the problems Alvaro fixed in 05fb5d661.
>> Unfortunately, there was no discussion marked on that commit message,
>> so it's not quite clear what the problem was. I'm unsure if there was
>> anything other than CLUSTER that was broken.

> After a bit of trawling through the archives, I found it here:
> https://www.postgresql.org/message-id/20180124162006.pmapfiznhgngwtjf%40alvherre.pgsql
> I think there was insufficient discussion and you're probably right that
> it wasn't the best fix.  I don't object to finding another fix.

FWIW, I don't see any big problem with what you did.  We'd need to
do something more like what David suggests if the planner ever has
a reason to consider partitioned indexes.  But as long as it does
not, why expend the time to build data structures representing them?
And we'd have to add code in quite a few places to ignore them,
once they're in indexlist.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: [EXTERNAL] Re: Support load balancing in libpq
Next
From: Peter Geoghegan
Date:
Subject: Re: Making C function declaration parameter names consistent with corresponding definition names