On Mon, Nov 16, 2015 at 8:35 AM, Tom Lane wrote:
> I wrote:
>> I experimented with using a hash table to avoid the O(N^2) behavior.
>> This seems to work quite well, and I think it doesn't change the results
>> (leastwise, it does not break the regression tests).
>
> Looking at this again in the l
I wrote:
> I experimented with using a hash table to avoid the O(N^2) behavior.
> This seems to work quite well, and I think it doesn't change the results
> (leastwise, it does not break the regression tests).
Looking at this again in the light of morning, it occurred to me that it's
pretty broken
Jeff Janes writes:
> On Fri, Nov 13, 2015 at 3:13 PM, Tom Lane wrote:
>> There's probably no reason not to do that, but I'd be much more interested
>> in eliminating the slowness to begin with ...
> I was thinking about that as well, but I don't think that would be
> back-patchable, at least not
On Fri, Nov 13, 2015 at 3:13 PM, Tom Lane wrote:
> Jeff Janes writes:
>> Someone sent my server a deranged query, it tripped my
>> auto_explain.log_min_duration setting, that hit some kind of
>> pathological case while assigning aliases, and now it sits
>> uninterruptibly in set_rtable_names for
Jeff Janes writes:
> Someone sent my server a deranged query, it tripped my
> auto_explain.log_min_duration setting, that hit some kind of
> pathological case while assigning aliases, and now it sits
> uninterruptibly in set_rtable_names for hours.
> Is there any reason we can't check for interru
Someone sent my server a deranged query, it tripped my
auto_explain.log_min_duration setting, that hit some kind of
pathological case while assigning aliases, and now it sits
uninterruptibly in set_rtable_names for hours.
Is there any reason we can't check for interrupts in set_rtable_names,
like
