On Thu, Apr 18, 2019 at 4:09 AM John Naylor <john.naylor@2ndquadrant.com> wrote:
> On Thu, Apr 18, 2019 at 1:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > John Naylor <john.naylor@2ndquadrant.com> writes:
> > > Attached is a patch to fix some minor issues:
> > > -misspelling of an error message
> >
> > Yeah, I'd noticed that one too :-(. I think the whole jsonpath patch
> > needs a sweep to bring its error messages into line with our style
> > guidelines, but no harm in starting with the obvious bugs.
> >
> > > -Commit 550b9d26f80f failed to update the Makefile comment to reflect
> > > how the build changed, and also removed the clean target, which we now
> > > have use for since we later got rid of backtracking in the scanner.
> >
> > Right. I'm not really sure why we're bothering with anti-backtracking
> > here, or with using speed-rather-than-code-space lexer optimization
> > options. It's hard for me to credit that any practically-useful jsonpath
> > pattern would be long enough for lexer speed to matter, and even harder to
> > credit that the speed of the flex code itself would be an important factor
> > in the overall processing cost of a long jsonpath. Still, as long as we
> > have the code it needs to be right.
>
> I was wondering about that. I measured the current size of
> yy_transition to be 36492 on my machine. With the flag -Cfe, which
> gives the smallest representation without backtracking, yy_nxt is 6336
> (there is no yy_transition). I'd say that's a large enough difference
> that we'd want the smaller representation if it makes little
> difference in performance.
Did I understand correctly that you've tried the same version of
jsonpath_scan.l with different flex flags? Did you also notice if
changes 1d88a75c made to jsonpath_scan.l have singnificant influence?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company