David Rowley wrote: > I wonder if it should be this patches job to alter the code in > get_relation_info() which causes the indexes not to be loaded for > partitioned tables: > > /* > * Make list of indexes. Ignore indexes on system catalogs if told to. > * Don't bother with indexes for an inheritance parent, either. > */ > if (inhparent || > (IgnoreSystemIndexes && IsSystemRelation(relation))) > hasindex = false; > else > hasindex = relation->rd_rel->relhasindex; > > A partitioned table will always go into the hasindex = false code path. > > I'm kind of thinking this patch should change that, even if the patch is > not making use of the indexes, you could argue that something > using set_rel_pathlist_hook might want to do something there, although, > there's likely a bunch of counter arguments too. > > What do you think?
Great question. So you're thinking that the planner might have an interest in knowing what indexes are defined at the parent table level for planning purposes; but for that to actually have any effect we would need to change the planner and executor also. And one more point, also related to something you said before: we currently (I mean after my patch) don't mark partitioned-table-level indexes as valid or not valid depending on whether all its children exist, so trying to use that in the planner without having a flag could cause invalid plans to be generated (i.e. ones that would cause nonexistent indexes to be referenced). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
