On 09/25/2014 09:05 PM, Thom Brown wrote:
On 12 March 2014 16:29, Heikki Linnakangas wrote:
Good point. We have done two major changes to GIN in this release cycle:
changed the data page format and made it possible to skip items without
fetching all the keys ("fast scan"). gincostestimate doesn
On 12 March 2014 16:29, Heikki Linnakangas wrote:
> Good point. We have done two major changes to GIN in this release cycle:
> changed the data page format and made it possible to skip items without
> fetching all the keys ("fast scan"). gincostestimate doesn't know about
> either change.
Did thi
On Thu, Mar 13, 2014 at 8:58 PM, Heikki Linnakangas wrote:
> On 03/12/2014 07:52 PM, Alexander Korotkov wrote:
>
>> >
>>> >* I just noticed that the dummy trueTriConsistentFn returns GIN_MAYBE,
>>> >rather than GIN_TRUE. The equivalent boolean version returns 'true'
>>> without
>>> >recheck. Is t
On 03/12/2014 07:52 PM, Alexander Korotkov wrote:
>
>* I just noticed that the dummy trueTriConsistentFn returns GIN_MAYBE,
>rather than GIN_TRUE. The equivalent boolean version returns 'true' without
>recheck. Is that a typo, or was there some reason for the discrepancy?
>
Actually, there is no
On 03/12/2014 07:42 PM, Alexander Korotkov wrote:
Preparation we do in startScanKey requires knowledge of estimate size of
posting lists/trees. We do this estimate by traversal to leaf pages. I
think gincostestimate is expected to be way more cheap. So, we probably
need so more rough estimate the
On Wed, Mar 12, 2014 at 1:52 PM, Alexander Korotkov
wrote:
>> * This patch added a triConsistent function for array and tsvector
>> opclasses. Were you planning to submit a patch to do that for the rest of
>> the opclasses, like pg_trgm? (it's getting awfully late for that...)
>
> Yes. I can try t
On Wed, Mar 12, 2014 at 8:02 PM, Heikki Linnakangas wrote:
> On 02/26/2014 11:25 PM, Alexander Korotkov wrote:
>
>> On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov > >wrote:
>>
>> On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com> wrote:
>>>
>>> On 02/09/2014
On Wed, Mar 12, 2014 at 8:29 PM, Heikki Linnakangas wrote:
> On 03/12/2014 12:09 AM, Tomas Vondra wrote:
>
>> Hi all,
>>
>> a quick question that just occured to me - do you plan to tweak the cost
>> estimation fot GIN indexes, in this patch?
>>
>> IMHO it would be appropriate, given the improvem
On 03/12/2014 12:09 AM, Tomas Vondra wrote:
Hi all,
a quick question that just occured to me - do you plan to tweak the cost
estimation fot GIN indexes, in this patch?
IMHO it would be appropriate, given the improvements and gains, but it
seems to me gincostestimate() was not touched by this pa
On 02/26/2014 11:25 PM, Alexander Korotkov wrote:
On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov wrote:
On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
I've rebased catalog changes with last master.
Hi all,
a quick question that just occured to me - do you plan to tweak the cost
estimation fot GIN indexes, in this patch?
IMHO it would be appropriate, given the improvements and gains, but it
seems to me gincostestimate() was not touched by this patch.
I just ran into this while testing some
On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov wrote:
> On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
>>
>>> I've rebased catalog changes with last master. Patch is attached. I've
>>> rerun my tes
On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas wrote:
> On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
>
>> I've rebased catalog changes with last master. Patch is attached. I've
>> rerun my test suite with both last master ('committed') and attached
>> patch ('ternary-consistent').
>>
>
On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
I've rebased catalog changes with last master. Patch is attached. I've
rerun my test suite with both last master ('committed') and attached
patch ('ternary-consistent').
Thanks!
method | sum
+---
On 9.2.2014 22:51, Erik Rijkers wrote:
> On Sun, February 9, 2014 22:35, Tomas Vondra wrote:
>> On 3.2.2014 07:53, Oleg Bartunov wrote:
>>> PS. I used data delicious-rss-1250k.gz from
>>> http://randomwalker.info/data/delicious/
>>
>> I'm working on extending the GIN testing to include this test (a
On Sun, February 9, 2014 22:35, Tomas Vondra wrote:
> On 3.2.2014 07:53, Oleg Bartunov wrote:
>> PS. I used data delicious-rss-1250k.gz from
>> http://randomwalker.info/data/delicious/
>
> I'm working on extending the GIN testing to include this test (and I'll
> use it to test both for GIN and hsto
On 3.2.2014 07:53, Oleg Bartunov wrote:
> Tomasa, it'd be nice if you use real data in your testing.
>
> One very good application of gin fast-scan is dramatic performance
> improvement of hstore/jsonb @> operator, see slides 57, 58
> http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-201
On Fri, Feb 7, 2014 at 5:33 PM, Heikki Linnakangas
wrote:
> On 02/06/2014 01:22 PM, Alexander Korotkov wrote:
>
>> Difference is very small. For me, it looks ready for commit.
>>
>
> Great, committed!
>
> Now, to review the catalog changes...
I've rebased catalog changes with last master. Patch
On 02/06/2014 01:22 PM, Alexander Korotkov wrote:
Difference is very small. For me, it looks ready for commit.
Great, committed!
Now, to review the catalog changes...
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Thu, Feb 6, 2014 at 2:21 PM, Heikki Linnakangas
wrote:
> On 02/05/2014 12:42 PM, Alexander Korotkov wrote:
>
>> Attached patch is "light" version of fast scan. It does extra consistent
>> function calls only on startScanKey, no extra calls during scan of the
>> index.
>> It finds subset of rare
On 02/05/2014 12:42 PM, Alexander Korotkov wrote:
Attached patch is "light" version of fast scan. It does extra consistent
function calls only on startScanKey, no extra calls during scan of the
index.
It finds subset of rarest entries absence of which guarantee false
consistent function result.
On Wed, Feb 5, 2014 at 1:23 AM, Alexander Korotkov wrote:
> On Mon, Feb 3, 2014 at 6:31 PM, Alexander Korotkov
> wrote:
>
>> On Mon, Jan 27, 2014 at 7:30 PM, Alexander Korotkov > > wrote:
>>
>>> On Mon, Jan 27, 2014 at 2:32 PM, Alexander Korotkov <
>>> aekorot...@gmail.com> wrote:
>>>
Every
On Mon, Feb 3, 2014 at 6:31 PM, Alexander Korotkov wrote:
> On Mon, Jan 27, 2014 at 7:30 PM, Alexander Korotkov
> wrote:
>
>> On Mon, Jan 27, 2014 at 2:32 PM, Alexander Korotkov > > wrote:
>>
>>> On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com> wrote:
>>>
On
On 3 Únor 2014, 19:18, Alexander Korotkov wrote:
> On Mon, Feb 3, 2014 at 8:19 PM, Tomas Vondra wrote:
>
>> > > Sometimes test cases are not what we expect. For example:
>> >> >
>> >> > =# explain SELECT id FROM messages WHERE body_tsvector @@
>> >> > to_tsquery('english','(5alpha1-initdb''d)');
On Mon, Feb 3, 2014 at 8:19 PM, Tomas Vondra wrote:
> > > Sometimes test cases are not what we expect. For example:
> >> >
> >> > =# explain SELECT id FROM messages WHERE body_tsvector @@
> >> > to_tsquery('english','(5alpha1-initdb''d)');
> >> >QU
On 3 Únor 2014, 17:08, Alexander Korotkov wrote:
> On Mon, Feb 3, 2014 at 7:24 PM, Tomas Vondra wrote:
>
>> On 3 Únor 2014, 15:31, Alexander Korotkov wrote:
>> >
>> > I found my patch "0005-Ternary-consistent-implementation.patch" to be
>> > completely wrong. It introduces ternary consistent funct
On Mon, Feb 3, 2014 at 7:24 PM, Tomas Vondra wrote:
> On 3 Únor 2014, 15:31, Alexander Korotkov wrote:
> >
> > I found my patch "0005-Ternary-consistent-implementation.patch" to be
> > completely wrong. It introduces ternary consistent function to opclass,
> > but
> > don't uses it, because I for
On Thu, Jan 30, 2014 at 8:38 PM, Heikki Linnakangas wrote:
> On 01/30/2014 01:53 AM, Tomas Vondra wrote:
>
>> (3) A file with explain plans for 4 queries suffering ~2x slowdown,
>> and explain plans with 9.4 master and Heikki's patches is available
>> here:
>>
>>http://www.fuzzy
Hi Alexander,
On 3 Únor 2014, 15:31, Alexander Korotkov wrote:
>
> I found my patch "0005-Ternary-consistent-implementation.patch" to be
> completely wrong. It introduces ternary consistent function to opclass,
> but
> don't uses it, because I forgot to include ginlogic.c change into patch.
> So,
On Mon, Jan 27, 2014 at 7:30 PM, Alexander Korotkov wrote:
> On Mon, Jan 27, 2014 at 2:32 PM, Alexander Korotkov
> wrote:
>
>> On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> On 01/26/2014 08:24 AM, Tomas Vondra wrote:
>>>
Hi!
On 25.1
On 03/02/14 02:44, Tomas Vondra wrote:
(2) The question is whether the new patch works fine on rare words. See
this for comparison of the patches against HEAD:
http://www.fuzzy.cz/tmp/gin/3-rare-words.png
http://www.fuzzy.cz/tmp/gin/3-rare-words-new.png
and this is the c
Hi Oleg,
On 3 Únor 2014, 7:53, Oleg Bartunov wrote:
> Tomasa, it'd be nice if you use real data in your testing.
I'm using a mailing list archive (the benchmark is essentially a simple
search engine on top of the archive, implemented using built-in
full-text). So I think this is a quite 'real' da
Tomasa, it'd be nice if you use real data in your testing.
One very good application of gin fast-scan is dramatic performance
improvement of hstore/jsonb @> operator, see slides 57, 58
http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf.
I'd like not to lost this benefit :)
Oleg
On 2.2.2014 11:45, Heikki Linnakangas wrote:
> On 01/30/2014 01:53 AM, Tomas Vondra wrote:
>> (3) A file with explain plans for 4 queries suffering ~2x slowdown,
>> and explain plans with 9.4 master and Heikki's patches is available
>> here:
>>
>>http://www.fuzzy.cz/tmp/gin/querie
On 01/30/2014 01:53 AM, Tomas Vondra wrote:
(3) A file with explain plans for 4 queries suffering ~2x slowdown,
and explain plans with 9.4 master and Heikki's patches is available
here:
http://www.fuzzy.cz/tmp/gin/queries.txt
All the queries have 6 common words, and the ex
On 01/30/2014 01:53 AM, Tomas Vondra wrote:
(3) A file with explain plans for 4 queries suffering ~2x slowdown,
and explain plans with 9.4 master and Heikki's patches is available
here:
http://www.fuzzy.cz/tmp/gin/queries.txt
All the queries have 6 common words, and the ex
On 28.1.2014 08:29, Heikki Linnakangas wrote:
> On 01/28/2014 05:54 AM, Tomas Vondra wrote:
>> Then I ran those scripts on:
>>
>>* 9.3
>>* 9.4 with Heikki's patches (9.4-heikki)
>>* 9.4 with Heikki's and first patch (9.4-alex-1)
>>* 9.4 with Heikki's and both patches (9.4-alex-2)
>
On 01/28/2014 05:54 AM, Tomas Vondra wrote:
Then I ran those scripts on:
* 9.3
* 9.4 with Heikki's patches (9.4-heikki)
* 9.4 with Heikki's and first patch (9.4-alex-1)
* 9.4 with Heikki's and both patches (9.4-alex-2)
It would be good to also test with unpatched 9.4 (ie. git maste
On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas wrote:
> In addition to that, I'm using the ternary consistent function to check
>> if minItem is a match, even if we haven't loaded all the entries yet.
>> That's less important, but I think for something like "rare1 | (rare2 &
>> frequent)" it
On Sun, Jan 26, 2014 at 8:14 PM, Heikki Linnakangas wrote:
> On 01/26/2014 08:24 AM, Tomas Vondra wrote:
>
>> Hi!
>>
>> On 25.1.2014 22:21, Heikki Linnakangas wrote:
>>
>>> Attached is a new version of the patch set, with those bugs fixed.
>>>
>>
>> I've done a bunch of tests with all the 4 patch
On 26.1.2014 17:14, Heikki Linnakangas wrote:
>
> I would actually expect it to be fairly effective for that query, so
> that's a bit surprising. I added counters to see where the calls are
> coming from, and it seems that about 80% of the calls are actually
> coming from this little the feature I
On 01/26/2014 08:24 AM, Tomas Vondra wrote:
Hi!
On 25.1.2014 22:21, Heikki Linnakangas wrote:
Attached is a new version of the patch set, with those bugs fixed.
I've done a bunch of tests with all the 4 patches applied, and it seems
to work now. I've done tests with various conditions (AND/OR
On 2014-01-26 07:24:58 +0100, Tomas Vondra wrote:
> Not sure how to interpret that, though. For example where did the
> ginCompareItemPointers go? I suspect it's thanks to inlining, and that
> it might be related to the performance decrease. Or maybe not.
Try recompiling with CFLAGS="-fno-omit-fra
Hi!
On 25.1.2014 22:21, Heikki Linnakangas wrote:
> Attached is a new version of the patch set, with those bugs fixed.
I've done a bunch of tests with all the 4 patches applied, and it seems
to work now. I've done tests with various conditions (AND/OR, number of
words, number of conditions) and I
On 23.1.2014 17:22, Heikki Linnakangas wrote:
> I measured the time that query takes, and the number of pages hit, using
> "explain (analyze, buffers true) ...".
>
> patchestime (ms)buffers
> ---
> unpatched6501316
> patch 10.521316
> patches 1+20.50
On 01/24/2014 01:58 PM, Alexander Korotkov wrote:
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas
wrote:
In summary, these are fairly small patches, and useful on their, so I
think these should be committed now. But please take a look and see if the
logic in scanGetItem/keyGetItem looks c
On Thu, Jan 23, 2014 at 8:22 PM, Heikki Linnakangas wrote:
> On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
>
>> Attached version is rebased against last version of packed posting lists.
>>
>
> Thanks!
>
> I think we're missing a trick with multi-key queries. We know that when
> multiple scan
On Fri, Jan 24, 2014 at 6:48 AM, Tomas Vondra wrote:
> I plan to do more thorough testing over the weekend, but I'd like to
> make sure I understand what to expect. My understanding is that this
> patch should:
>
> - give the same results as the current code (e.g. the fulltext should
> not retu
On 23.1.2014 17:22, Heikki Linnakangas wrote:
> On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
>> Attached version is rebased against last version of packed posting lists.
>
> Thanks!
>
> I think we're missing a trick with multi-key queries. We know that when
> multiple scan keys are used, the
On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
Attached version is rebased against last version of packed posting lists.
Thanks!
I think we're missing a trick with multi-key queries. We know that when
multiple scan keys are used, they are ANDed together, so we can do the
skip optimization
On Tue, Jan 14, 2014 at 11:07 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
>
>> On Thu, Nov 21, 2013 at 12:14 AM, Alexander Korotkov
>> wrote:
>>
>> Revised version of patch is attached. Changes are so:
>>> 1) Support for GinFuzzySea
On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
On Thu, Nov 21, 2013 at 12:14 AM, Alexander Korotkov
wrote:
Revised version of patch is attached. Changes are so:
1) Support for GinFuzzySearchLimit.
2) Some documentation.
Question about GinFuzzySearchLimit is still relevant.
Attached versio
On Thu, Nov 21, 2013 at 12:14 AM, Alexander Korotkov
wrote:
> On Wed, Nov 20, 2013 at 3:06 AM, Alexander Korotkov
> wrote:
>
>> On Fri, Nov 15, 2013 at 11:19 AM, Alexander Korotkov <
>> aekorot...@gmail.com> wrote:
>>
>>> On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas <
>>> hlinnakan...@vmw
On Wed, Nov 20, 2013 at 3:06 AM, Alexander Korotkov wrote:
> On Fri, Nov 15, 2013 at 11:19 AM, Alexander Korotkov > wrote:
>
>> On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> On 14.11.2013 19:26, Alexander Korotkov wrote:
>>>
On Sun, Jun 30,
On Fri, Nov 15, 2013 at 11:19 AM, Alexander Korotkov
wrote:
> On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 14.11.2013 19:26, Alexander Korotkov wrote:
>>
>>> On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com
>>>
>>
I tried again this morning using gin-packed-postinglists-16.patch and
gin-fast-scan.6.patch. No crashes.
It is about a 0.1% random sample of production data (10,000,000 records)
with the below structure. Pg was compiled with debug enabled in both cases.
Table "public.kp"
Column | Type |
I checked out master and put together a test case using a small percentage
of production data for a known problem we have with Pg 9.2 and text search
scans.
A small percentage in this case means 10 million records randomly selected;
has a few billion records.
Tests ran for master successfully an
On Fri, Nov 15, 2013 at 2:42 PM, Alexander Korotkov wrote:
> On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor wrote:
>
>>
>> The patched index is 58% of the 9.4 master size. 212 MB instead of 365 MB.
>>
>
> Good. That's meet my expectations :)
> You mention that both master and patched versions was c
On Fri, Nov 15, 2013 at 11:42 PM, Alexander Korotkov
wrote:
> On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor wrote:
>
>>
>>
>>
>> On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov > > wrote:
>>
>>> On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote:
>>>
2%.
It's essentially sentenc
On Sat, Nov 16, 2013 at 12:10 AM, Peter Eisentraut wrote:
> On 11/14/13, 12:26 PM, Alexander Korotkov wrote:
> > Revised version of patch is attached.
>
> This doesn't build:
>
> ginget.c: In function ‘scanPage’:
> ginget.c:1108:2: warning: implicit declaration of function
> ‘GinDataLeafPageGetPo
On 11/14/13, 12:26 PM, Alexander Korotkov wrote:
> Revised version of patch is attached.
This doesn't build:
ginget.c: In function ‘scanPage’:
ginget.c:1108:2: warning: implicit declaration of function
‘GinDataLeafPageGetPostingListEnd’ [-Wimplicit-function-declaration]
ginget.c:1108:9: warning:
On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor wrote:
>
>
>
> On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov
> wrote:
>
>> On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote:
>>
>>> 2%.
>>>
>>> It's essentially sentence fragments from 1 to 5 words in length. I
>>> wasn't expecting it to be mu
On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov wrote:
> On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote:
>
>> 2%.
>>
>> It's essentially sentence fragments from 1 to 5 words in length. I wasn't
>> expecting it to be much smaller.
>>
>> 10 recent value selections:
>>
>> white vinegar redu
On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor wrote:
> 2%.
>
> It's essentially sentence fragments from 1 to 5 words in length. I wasn't
> expecting it to be much smaller.
>
> 10 recent value selections:
>
> white vinegar reduce color running
> vinegar cure uti
> cane vinegar acidity depends pa
2%.
It's essentially sentence fragments from 1 to 5 words in length. I wasn't
expecting it to be much smaller.
10 recent value selections:
white vinegar reduce color running
vinegar cure uti
cane vinegar acidity depends parameter
how remedy fir clogged shower
use vinegar sensitive skin
hom
On Fri, Nov 15, 2013 at 6:57 PM, Rod Taylor wrote:
> I tried again this morning using gin-packed-postinglists-16.patch and
> gin-fast-scan.6.patch. No crashes.
>
> It is about a 0.1% random sample of production data (10,000,000 records)
> with the below structure. Pg was compiled with debug enabl
I tried again this morning using gin-packed-postinglists-16.patch and
gin-fast-scan.6.patch. No crashes during index building.
Pg was compiled with debug enabled in both cases. The data is a ~0.1%
random sample of production data (10,000,000 records for the test) with the
below structure.
T
On Fri, Nov 15, 2013 at 12:34 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 14.11.2013 19:26, Alexander Korotkov wrote:
>
>> On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com
>>
>>> wrote:
>>>
>>
>> On 28.06.2013 22:31, Alexander Korotkov wrote:
>>>
On Fri, Nov 15, 2013 at 3:25 AM, Rod Taylor wrote:
> I checked out master and put together a test case using a small percentage
> of production data for a known problem we have with Pg 9.2 and text search
> scans.
>
> A small percentage in this case means 10 million records randomly
> selected; ha
On 14.11.2013 19:26, Alexander Korotkov wrote:
On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas
wrote:
On 28.06.2013 22:31, Alexander Korotkov wrote:
Now, I got the point of three state consistent: we can keep only one
consistent in opclasses that support new interface. exact true and ex
On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas wrote:
> On 28.06.2013 22:31, Alexander Korotkov wrote:
>
>> Now, I got the point of three state consistent: we can keep only one
>> consistent in opclasses that support new interface. exact true and exact
>> false values will be passed in the c
Hi,
this is a follow-up to the message I posted to the thread about
additional info in GIN.
I've applied both ginaddinfo.7.patch and gin_fast_scan.4.patch on commit
b8fd1a09, but I'm observing a lot of failures like this:
STATEMENT: SELECT id FROM messages WHERE body_tsvector @@
plainto_tsquery
On 28.06.2013 22:31, Alexander Korotkov wrote:
Now, I got the point of three state consistent: we can keep only one
consistent in opclasses that support new interface. exact true and exact
false values will be passed in the case of current patch consistent; exact
false and unknown will be passed
On Tue, Jun 25, 2013 at 2:20 AM, Alexander Korotkov wrote:
> 4. If we do go with a new function, I'd like to just call it "consistent"
>> (or consistent2 or something, to keep it separate form the old consistent
>> function), and pass it a tri-state input for each search term. It might not
>> be a
On Fri, Jun 21, 2013 at 11:43 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 19.06.2013 11:56, Alexander Korotkov wrote:
>
>> On Wed, Jun 19, 2013 at 12:49 PM, Heikki Linnakangas<
>> hlinnakan...@vmware.com> wrote:
>>
>> On 19.06.2013 11:30, Alexander Korotkov wrote:
>>>
>>> On W
On 19.06.2013 11:56, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 12:49 PM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
On 19.06.2013 11:30, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
On 18.06.2013 23:59,
On Wed, Jun 19, 2013 at 12:49 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 19.06.2013 11:30, Alexander Korotkov wrote:
>
>> On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas<
>> hlinnakan...@vmware.com> wrote:
>>
>> On 18.06.2013 23:59, Alexander Korotkov wrote:
>>>
>>> I wo
On 19.06.2013 11:30, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
On 18.06.2013 23:59, Alexander Korotkov wrote:
I would like to illustrate that on example. Imagine you have fulltext
query
"rare_term& frequent_term". Freque
On Wed, Jun 19, 2013 at 12:30 PM, Alexander Korotkov
wrote:
> On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 18.06.2013 23:59, Alexander Korotkov wrote:
>>
>>> I would like to illustrate that on example. Imagine you have fulltext
>>> query
>>> "rar
On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 18.06.2013 23:59, Alexander Korotkov wrote:
>
>> I would like to illustrate that on example. Imagine you have fulltext
>> query
>> "rare_term& frequent_term". Frequent term has large posting tree while
>>
On 18.06.2013 23:59, Alexander Korotkov wrote:
I would like to illustrate that on example. Imagine you have fulltext query
"rare_term& frequent_term". Frequent term has large posting tree while
rare term has only small posting list containing iptr1, iptr2 and iptr3. At
first we get iptr1 from po
On Mon, Jun 17, 2013 at 5:09 PM, Heikki Linnakangas wrote:
> On 17.06.2013 15:55, Alexander Korotkov wrote:
>
>> On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkov
>> **wrote:
>>
>> attached patch implementing "fast scan" technique for GIN. This is second
>>> patch of GIN improvements, see the
On 17.06.2013 15:55, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkovwrote:
attached patch implementing "fast scan" technique for GIN. This is second
patch of GIN improvements, see the 1st one here:
http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwga
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkov wrote:
> attached patch implementing "fast scan" technique for GIN. This is second
> patch of GIN improvements, see the 1st one here:
>
> http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwgakfxijwm63_hzujacrxn...@mail.gmail.com
> Th
Hackes,
attached patch implementing "fast scan" technique for GIN. This is second
patch of GIN improvements, see the 1st one here:
http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwgakfxijwm63_hzujacrxn...@mail.gmail.com
This patch allow to skip parts of posting trees when their scan
85 matches
Mail list logo
