Re: [GENERAL] Unexpected planner behavior with *_pattern_ops index matching

2014-10-30 Thread Tom Lane
Fabio Ugo Venchiarutti writes: >>> Conversion of the pattern to an index qualification requires that the >>> pattern be a plan-time constant. STABLE functions, by definition, >>> are not that. > I guess it is correct to assume that the same applies to regular > expressions stored in pl/pgsql va

Re: [GENERAL] Unexpected planner behavior with *_pattern_ops index matching

2014-10-30 Thread Fabio Ugo Venchiarutti
> Conversion of the pattern to an index qualification requires that the > pattern be a plan-time constant. STABLE functions, by definition, > are not that. Thank you very much I guess it is correct to assume that the same applies to regular expressions stored in pl/pgsql variables/arguments t

Re: [GENERAL] Unexpected planner behavior with *_pattern_ops index matching

2014-10-30 Thread Tom Lane
Fabio Ugo Venchiarutti writes: > As you can see, CONCAT()'s output isn't deemed suitable for an index > scan. The same happens for all type-compatible STABLE functions i tried. Conversion of the pattern to an index qualification requires that the pattern be a plan-time constant. STABLE function

[GENERAL] Unexpected planner behavior with *_pattern_ops index matching

2014-10-29 Thread Fabio Ugo Venchiarutti
Greetings. I'm in the process of indexing a virtual file system (on 9.2.9, build info below) and I ran into what I perceive as an inconsistency in the way index viability is assessed by the planner. Perhaps I'm misinterpreting the docs, but it seems like stable functions don't behave as per