On Thu, Feb 18, 2016 at 11:05 PM, Tom Lane wrote:
> Victor Blomqvist writes:
> > We just had a major issue on our databases, after a index was replaced a
> > user defined function didnt change its query plan to use the new index.
>
> I'm suspicious that this is some variant of the problem discus
Victor Blomqvist writes:
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index.
I'm suspicious that this is some variant of the problem discussed a couple
days ago:
http://www.postgresql.org/message-id/
On 2/18/16, Victor Blomqvist wrote:
> Hello!
>
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index. At
> least this is our theory, since the function in question became much slower
> and as a result bro
The end goal is to get rid of index bloat. If there is a better way to
handle this Im all ears!
/Victor
On Thu, Feb 18, 2016 at 5:21 PM, Oleg Bartunov wrote:
>
>
> On Thu, Feb 18, 2016 at 11:17 AM, Victor Blomqvist wrote:
>
>> Hello!
>>
>> We just had a major issue on our databases, after a in
On Thu, Feb 18, 2016 at 11:17 AM, Victor Blomqvist wrote:
> Hello!
>
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index. At
> least this is our theory, since the function in question became much slowe
Hello!
We just had a major issue on our databases, after a index was replaced a
user defined function didnt change its query plan to use the new index. At
least this is our theory, since the function in question became much slower
and as a result brought our system to a halt.
Basically it went:
1
