Subject: Re: Uninterruptible long planning of a query with too many WHERE
 clauses
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <90c5bdfa-d633-dabe-9889-3cf3e1acd443@postgrespro.ru>
 <21010.1541911093@sss.pgh.pa.us>
From: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Message-ID: <37b95215-b315-ecbc-0747-037ac48ad4c4@postgrespro.ru>
Date: Mon, 12 Nov 2018 15:05:28 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <21010.1541911093@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

El 11/11/18 a las 07:38, Tom Lane escribió:
> I think you have the right basic idea, but we don't have to completely
> lobotomize the bitmap-and search logic in order to cope with this.
> This code is only trying to figure out which paths are potentially
> redundant, so for a path with too many quals, we can just deem it
> not-redundant, as attached.

Thanks for the patch, looks good to me.


> A different line of thought is that using equal() to compare quals
> here is likely overkill: plain old pointer equality ought to be enough,
> since what we are looking for is different indexpaths derived from the
> same members of the relation's baserestrictinfo list.

I didn't realize that we could just hash the pointers here, this 
simplifies things. But indeed it makes sense to just use a simpler logic 
for such extreme queries, because we won't have a good plan anyway.


> Another thought is that maybe we need a CHECK_FOR_INTERRUPTS call
> somewhere in here; but I'm not sure where would be a good place.
> I'm not excited about sticking one into classify_index_clause_usage,
> but adding one up at the per-path loops would not help for this case.

We added some interrupt checks as a quick fix for the client. In the 
long run, I think we don't have to add them, because normally, planning 
a query is relatively fast, and unexpected slowdowns like this one can 
still happen in places where we don't process interrupts.

-- 
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company