Re: Uninterruptible long planning of a query with too many WHERE clauses

From: Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Uninterruptible long planning of a query with too many WHERE clauses
Date: 2018-11-12 12:05:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-11-12 12:20:58 Re: doc fix for pg_stat_activity.backend_type
Previous Message Etsuro Fujita 2018-11-12 11:41:40 Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT