work with hypopg coredump

[HUST-Huyajun]

create extension hypopg ;
load 'pg_hint_plan';

create table t1(a int, b int, c int);
create index ON t1 (a);

select hypopg_create_index('create index on t1(b)');
explain select/*+ indexscan(t1 t1_a_idx)*/ from t1 where a = 3 and b =4 ;
-- coredump

it seems like pg_hint_plan does not consider the impact of hypothetical indexes, restrict_indexes should filter out the hypothetical IndexOptInfo in RelOptInfo

[michaelpq]

I'll look at producing a patch about that. For the time being, let's give a poke at @rjuju for the interactions with hypopg.

[rjuju]

Unfortunately there is nothing that hypopg can do to avoid that. It's a simple EXPLAIN so it does add a fake IndexOptInfo with a fake Oid. Then pg_hint_plan tries to call get_rel_name() with that fake index Oid, which is almost guaranteed to not point to a relation. I agree with @HUST-Huyajun, checking and ignoring hypothetical indexes is likely the only thing that can be done here. Unfortunately there is no API that hypopg can implement to let pg_hint_plan get the hypothetical index name, so you can't really use such an index in a hint.

[michaelpq]

I agree with @HUST-Huyajun, checking and ignoring hypothetical indexes is likely the only thing that can be done here.

Yep. I'm on the same line as you here. Ignoring them sounds like a sane option, even if from the user perspective it could be nice to create an hypothetical index and manipulate the plan paths with hints.

[rjuju]

Actually, I just remembered that there is an existing hook to get the hypothetical index name, as EXPLAIN needs it: explain_get_index_name_hook(). The naming is quite explicit, but I don't see any reason why we couldn't actually call the for a hypothetical index.