From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org, pavel(dot)stehule(at)gmail(dot)com |
Subject: | Re: WIP: index support for regexp search |
Date: | 2012-12-13 21:34:01 |
Message-ID: | CAPpHfduFOqnVBXxNtT3SRSyy0ju4WKL6OY9sYqY6HQF+W0gGag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 3, 2012 at 4:31 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>wrote:
> Actually, I generally dislike path matrix for same reasons. But:
> 1) Output graphs could contain trigrams which are completely useless for
> search. For example, for regex /(abcdefgh)*ijk/ we need only "ijk" trigram
> while graph would contain much more.Path matrix is a method to get rid of
> all of them.
> 2) If we use color trigrams then we need some criteria for which color
> trigrams to expand into trigrams. Simultaneously, we shouldn't allow path
> from initial state to the final by unexpanded trigrams. It seems much
> harder to do with graph than with matrix.
>
Now, I have an idea about doing some not comprehensive but simple and fast
simplification of graph. I'm doing experiments now. In case of success we
could get rid of path matrix.
------
With best regards,
Alexander Korotkov.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-12-13 22:11:31 | Re: Logical decoding & exported base snapshot |
Previous Message | Alexander Korotkov | 2012-12-13 21:31:02 | Re: SP-GiST for ranges based on 2d-mapping and quad-tree |