From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: fix for BUG #3720: wrong results at using ltree |
Date: | 2020-03-31 15:47:30 |
Message-ID: | 4902.1585669650@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I've marked this RFC, and will push tomorrow unless somebody wants
> to object to the loss of backwards compatibility.
And done. I noticed in some final testing that it's possible to
make this code take a long time by forcing it to backtrack a lot:
regression=# SELECT (('1' || repeat('.1', 65534))::ltree) ~ '*.*.x';
?column?
----------
f
(1 row)
Time: 54015.421 ms (00:54.015)
so I threw in a CHECK_FOR_INTERRUPTS(). Maybe it'd be worth trying
to optimize such cases, but I'm not sure that it'd ever matter for
real-world cases with reasonable-size label strings.
The old implementation seems to handle that particular case well,
evidently because it more-or-less folds adjacent stars together.
However, before anyone starts complaining about regressions, they
should note that it's really easy to get the old code to fail
via stack overflow:
regression=# SELECT (('1' || repeat('.1', 65534))::ltree) ~ '*.!1.*';
ERROR: stack depth limit exceeded
(That's as of five minutes ago, before that it dumped core.)
So I don't feel bad about the tradeoff. At least now we have
simple, visibly correct code that could serve as a starting
point for optimization if anyone feels the need to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Bashtanov | 2020-03-31 15:55:13 | Re: Less-silly selectivity for JSONB matching operators |
Previous Message | Alvaro Herrera | 2020-03-31 15:24:42 | Re: A rather hackish POC for alternative implementation of WITH TIES |