From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> |
Cc: | washwithcare(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Nikita Glukhov <glukhov(dot)n(dot)a(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: BUG #19031: pg_trgm infinite loop on certain cases |
Date: | 2025-08-27 14:32:26 |
Message-ID: | 1391111.1756305146@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> writes:
> Good point, thanks for the explanation. I forgot that there can be
> many attributes. And I agree, the more determinism in the system, the
> easier it is to work with it and the less room for bugs. OTOH it seems
> from the performance POV we want to have the stricter keys to be the
> first so we do less work and fail fast on the first keys. It looks
> like these two rules (excludeOnly keys LAST and more restrictive keys
> FIRST) are kind of in conflict with each other. I tried to do some
> experiments and it's seems GIN quite sensitive to it, at least in this
> artificial example:
Yeah, it is. I recall seeing some comments to the effect that
optimizing the order of scan keys would be a good thing, but if there
is any code in there that tries to do so, I'm not seeing where.
Seems like a fertile area for future research.
> With applying patch both queries show the same time (second one). So
> currently the user can tune the query by defining more restrictive
> keys first. With the proposed fix it looks like users will have less
> freedom here.
I think most people would consider it a bug if they have to tune the
order of the WHERE clauses manually. The original statement of the
current bug was basically that: it worked in one order and not the
other.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-08-27 14:38:11 | Re: BUG #19033: Inconsistency between prepared statement and normal statement when cast bit to integer |
Previous Message | Thadeus Anand | 2025-08-27 09:49:00 | Re: [CAUTION: SUSPECT SENDER] RE: [CAUTION: SUSPECT SENDER] RE: [CAUTION: SUSPECT SENDER] RE: [CAUTION: SUSPECT SENDER] RE: BUG #19029: Replication Slot size keeps increasing while logical subscription works fine |