> Andrey Borodin writes:
>
>> I've tried to toy with the patch and remembered one related caveat.
>> If we have index for both returnable and nonreturnable attributes, IOS will
>> not be choosen:
>
>> postgres=# create index on t using gist(a gist_trgm_ops) include (a);
>> postgres=# explain
Andrey Borodin writes:
> I've tried to toy with the patch and remembered one related caveat.
> If we have index for both returnable and nonreturnable attributes, IOS will
> not be choosen:
> postgres=# create index on t using gist(a gist_trgm_ops) include (a);
> postgres=# explain select * from
> regression=# explain select * from t where lower(a) like 'z';
> QUERY PLAN
> --
> Index Only Scan using t_lower_a_idx on t (cost=0.14..28.27 rows=7 width=32)
> Index Cond: ((lower(a)) ~~ 'z'::text)
> (2 rows)
>
I've
I wrote:
> Unless somebody's got a better idea, I'll push forward with making
> this happen.
Here's a proposed patch for that. I ended up reverting the code
changes of 4ace45677 in favor of an alternative I'd considered
previously, which is to mark the indextlist elements as resjunk
if they're no
Yesterday I pushed what I thought was a quick fix for bug #17350 [1].
In short, if we have an index that stores both "x" and "f(x)",
where the "x" column can be retrieved in index-only scans but "f(x)"
cannot, it's possible for the planner to generate an IOS plan that
nonetheless tries to read the
