Re: BUG #19031: pg_trgm infinite loop on certain cases
От | Arseniy Mukhin |
---|---|
Тема | Re: BUG #19031: pg_trgm infinite loop on certain cases |
Дата | |
Msg-id | CAE7r3M+Z_wMiJPTwzoR=roZC2+5NpyERJbumKMoTu7AmFC7Jug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #19031: pg_trgm infinite loop on certain cases (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #19031: pg_trgm infinite loop on certain cases
|
Список | pgsql-bugs |
On Wed, Aug 27, 2025 at 5:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Arseniy Mukhin <arseniy.mukhin.dev@gmail.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. > Ok. I checked the patches. The bug is gone. Everything looks correct. Thank you! Best regards, Arseniy Mukhin
В списке pgsql-bugs по дате отправления: