On Fri, Nov 15, 2013 at 11:42 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor rod.tay...@gmail.com wrote:
On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor rod.tay
On Fri, Nov 15, 2013 at 8:58 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/14/13, 6:00 AM, Alexander Korotkov wrote:
Sorry, I posted buggy version of patch. Attached version is correct.
This patch crashes the hstore the pg_trgm regression tests.
What exact version did you try 14 or 16
. Will be fixed soon.
BTW, was index 2% smaller or 2 times smaller? If it's 2% smaller than I
need to know more about your dataset :)
--
With best regards,
Alexander Korotkov.
On Fri, Nov 15, 2013 at 9:56 PM, Peter Eisentraut pete...@gmx.net wrote:
On 11/15/13, 12:24 PM, Alexander Korotkov wrote:
On Fri, Nov 15, 2013 at 8:58 PM, Peter Eisentraut pete...@gmx.net
mailto:pete...@gmx.net wrote:
On 11/14/13, 6:00 AM, Alexander Korotkov wrote:
Sorry, I
. Is it possible to share
dump?
--
With best regards,
Alexander Korotkov.
On Fri, Nov 15, 2013 at 11:39 PM, Rod Taylor rod.tay...@gmail.com wrote:
On Fri, Nov 15, 2013 at 2:26 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Fri, Nov 15, 2013 at 11:18 PM, Rod Taylor rod.tay...@gmail.comwrote:
2%.
It's essentially sentence fragments from 1 to 5 words
On Sat, Nov 16, 2013 at 12:10 AM, Peter Eisentraut pete...@gmx.net 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
On Tue, Nov 5, 2013 at 9:49 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 04.11.2013 23:44, Alexander Korotkov wrote:
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
Attached version of patch is debugged. I would like to note that number
of
bugs
On Thu, Nov 14, 2013 at 2:17 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Tue, Nov 5, 2013 at 9:49 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04.11.2013 23:44, Alexander Korotkov wrote:
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
aekorot...@gmail.comwrote
On Sun, Jun 30, 2013 at 3:00 PM, Heikki Linnakangas hlinnakan...@vmware.com
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
On Thu, Nov 14, 2013 at 3:00 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Nov 14, 2013 at 2:17 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Tue, Nov 5, 2013 at 9:49 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04.11.2013 23:44, Alexander Korotkov wrote
dump
The GIN index fails to build with a segfault.
Thanks for testing. See fixed version in thread about packed posting lists.
--
With best regards,
Alexander Korotkov.
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:
Now, I got the point
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
Attached version of patch is debugged. I would like to note that number of
bugs was low and it wasn't very hard to debug. I've rerun tests on it. You
can see that numbers are improved as the result of your
, not compress/decompress in general. I understand that in
general compress/decompress can do useful job.
--
With best regards,
Alexander Korotkov.
On Thu, Oct 10, 2013 at 3:57 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09.10.2013 02:04, Tomas Vondra wrote:
On 8.10.2013 21:59, Heikki Linnakangas wrote:
On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondrat...@fuzzy.cz
On Mon, Oct 21, 2013 at 11:06 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 11.10.2013 17:39, Alexander Korotkov wrote:
On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
2. I didn't understand this change
On Sat, Oct 12, 2013 at 1:55 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 10.10.2013 13:57, Heikki Linnakangas wrote:
On 09.10.2013 02:04, Tomas Vondra wrote:
On 8.10.2013 21:59, Heikki Linnakangas wrote:
On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3
related code. For example, in contrib/intarray/_int.h
#define SIGLENINT 63 /* 122 = key will *toast*, so very slow!!! */
Any ideas?
--
With best regards,
Alexander Korotkov.
:
PANIC: not enough space in leaf page!
Thanks for testing. Heikki's version of patch don't works for me too on
even much more simplier examples. I can try to get it working if he answer
my question about GinDataLeafPageGetPostingList* macros.
--
With best regards,
Alexander Korotkov.
.
In GinDataLeafPageGetPostingList* you use sizeof(ItemPointerData) without
MAXALIGN. Is it an error or you especially use 2 extra bytes on leaf page?
--
With best regards,
Alexander Korotkov.
almost whole index. Is it much better than just reindex?
4) Fork GIN2, leave GIN as is. It would lead to much of duplicated code.
Any other options?
--
With best regards,
Alexander Korotkov.
On Fri, Oct 4, 2013 at 12:41 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 03.10.2013 23:37, Alexander Korotkov wrote:
2) Insert kluges into GIN to support both old and new formats. So, kluges
are kluges :) I don't see elegant way to do it for now, because formats
are
very
On Fri, Oct 4, 2013 at 12:37 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Oct 3, 2013 at 10:48 PM, Robert Haas robertmh...@gmail.comwrote:
On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It seems we've all but decided that we'll require
On Wed, Sep 25, 2013 at 5:22 PM, Peter Eisentraut pete...@gmx.net wrote:
On 9/23/13 5:36 PM, Alexander Korotkov wrote:
In the attached version of patch double finding of ItemPointer during
insert is avoided. Overhead becomes lower as expected.
Fails cpluspluscheck:
./src/include/access
On Mon, Sep 23, 2013 at 12:47 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
It's probably an option to select 64 entries instead of 32.
There is still some regression in update speed. However, there is also
room for improvement patch. It searches item index entries 2 times on
insert
On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Alexander == Alexander Korotkov aekorot...@gmail.com writes:
Alexander 2) NaN coordinates should be processed in GiST index
On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth
and...@tao11.riddles.org.ukwrote:
Alexander == Alexander Korotkov aekorot...@gmail.com writes:
Alexander 2) NaN coordinates should be processed in GiST index scan
Alexander like in sequential scan.
postgres=# select * from pts order
On Mon, Sep 16, 2013 at 11:43 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.09.2013 12:14, Alexander Korotkov wrote:
On Sat, Jun 29, 2013 at 12:56 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
There's a few open questions:
1. How are we going to handle pg_upgrade
is fixed in attached version of
patch by introducing incremental updating of that index. Benchmarks will be
posted later today.
--
With best regards,
Alexander Korotkov.
gin-packed-postinglists-3.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Sat, Sep 7, 2013 at 1:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
PostGIS spotted that picksplit algorithm freezes in infinite loop when
dealing with nan values. I discovered same bug is present in core
opclasses. Attached patch fixes
of float8_cmp_internal rather than exposing it
from float.c, because it let compiler inline this function.
--
With best regards,
Alexander Korotkov.
picksplit-nan-fix-1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
a room for timing attack, but it
doesn't seem to be feasible in practice to apply.
--
With best regards,
Alexander Korotkov.
source NOT NULL,
within tstzrange NOT NULL,
EXCLUDE USING gist ((source::oid) WITH =, within WITH )
);
Probably, I'm missing something and casting enum to oid is somehow unsafe?
--
With best regards,
Alexander Korotkov.
://www.postgresql.org/docs/current/static/source-format.html
--
With best regards,
Alexander Korotkov.
On Sun, Jun 30, 2013 at 3:09 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 25.06.2013 21:18, Alexander Korotkov wrote:
On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
In summary: The test case you presented
for
packed postinglists.
2) Extract additional info patch based on packed postinglists.
3) Rewrite interface of fast scan. Do CPU and IO benchmarking.
4) Do IO benchmarking of index ordering.
Cleanup, comments and READMEs are assumed in each item.
--
With best regards,
Alexander Korotkov.
On Thu, Jun 27, 2013 at 6:20 PM, Antonin Houska antonin.hou...@gmail.comwrote:
On 06/25/2013 12:03 AM, Alexander Korotkov wrote:
New revision of patch is attached. Now it includes some docs.
Hi,
I was curious about the new layout of the data page, so I spent a while
looking
On Tue, Jun 25, 2013 at 2:20 AM, Alexander Korotkov aekorot...@gmail.comwrote:
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
On Thu, Jun 27, 2013 at 4:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 26, 2013 at 10:22 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
at last developer meeting we missed Oleg Bartunov. So, it's not
surprising
that photos is also missed.
I remember that somebody took
it on the website. So, it would be very nice to have a photo of developer
meeting.
Does anybody have it?
--
With best regards,
Alexander Korotkov.
On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 25.06.2013 01:24, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkovaekorot...@gmail.com
**wrote:
On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com
On Wed, Jun 19, 2013 at 12:44 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
Revised version of patch for additional
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 Wed, Jun 19, 2013
On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 17.06.2013 15:56, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkovaekorot...@gmail.com
**wrote
. The idea is to keep trying to remove
color trigrams from graph even when it fits into MAX_TRGM_SIZE, because we
are intending to scan less posting lists/trees.
Comments is not fixed yet, coming soon.
--
With best regards,
Alexander Korotkov.
trgm_regex_optimize.1.patch
Description: Binary data
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
rare term has
On Wed, Jun 19, 2013 at 12:30 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
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
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 would like
no objection, I'd like to mark the patch ready for
committer.
Sorry, I've had a cleanup of the patch. Please find attached the patch.
I've checked the attached patch. It looks good for me. No objection to mark
it ready for committer.
--
With best regards,
Alexander Korotkov.
On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
Revised version of patch for additional information storage in GIN is
attached. Changes are mostly bug fixes.
New version
On Mon, Jun 17, 2013 at 5:09 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 17.06.2013 15:55, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkovaekorot...@gmail.com
**wrote:
attached patch implementing fast scan technique for GIN. This is second
patch
On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 17.06.2013 15:56, Alexander Korotkov wrote:
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkovaekorot...@gmail.com
**wrote:
This patch introduces new interface method of GIN which takes same
arguments
On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
Revised version of patch for additional information storage in GIN is
attached. Changes are mostly bug fixes.
New version of patch is attached with some more refactoring and bug fixes.
--
With best regards
On Sat, Jun 15, 2013 at 2:55 AM, Alexander Korotkov aekorot...@gmail.comwrote:
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
On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkov aekorot...@gmail.comwrote:
attached patch implementing ordering inside GIN index. This is third patch
of GIN improvements, see previous two:
http://www.postgresql.org/message-id/capphfduxv-il7aedwpw0w5fxrwgakfxijwm63_hzujacrxn
)
--
With best regards,
Alexander Korotkov.
gin_fast_scan.1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
'''::tsquery)
Order By: (tsvector '''statist'''::tsquery)
Total runtime: 7.556 ms
(5 rows)
--
With best regards,
Alexander Korotkov.
information storage itself (because it don't accelerate tsearch
itselt). It comes in separate thread.
--
With best regards,
Alexander Korotkov.
ginaddinfo.4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
: 110.870 ms
(5 rows)
--
With best regards,
Alexander Korotkov.
index_on_regexes.1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 14, 2013 at 1:30 AM, Erik Rijkers e...@xs4all.nl wrote:
On Thu, June 13, 2013 22:19, Alexander Korotkov wrote:
[index_on_regexes.1.patch.gz ]
Hi,
Compile of core is OK, but contrib compilation fails:
-- [2013.06.13 23:23:14 idxregex] make contrib
trgm_gin.c: In function
it based on pg_trgm, because
of many hard-wired assumptions that trigram is fixed length and
compatibility.
--
With best regards,
Alexander Korotkov.
of CRC independently of KEEPONLYALNUM.
--
With best regards,
Alexander Korotkov.
regards,
Alexander Korotkov.
TABLE
test=# insert into cube_test values (cube(array[1,2])),
(cube(array[1,2,3]));
INSERT 0 2
In order to force all cubes to have same number of dimensions excplicit
CHECK on table is required.
As I remember cube treats absent dimensions as zeros.
--
With best regards,
Alexander Korotkov.
On Wed, May 8, 2013 at 3:50 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 06.05.2013 14:10, Alexander Korotkov wrote:
On Sat, May 4, 2013 at 10:27 PM, Alexander Korotkovaekorot...@gmail.com
**wrote:
In suffix tree we insert every suffix of source string into the tree.
http
of arrays
3) 2d arrays
Semantically cube is most close to array or ranges. However array of ranges
have huge storage overhead.
Also we can declare cube as domain on 2d arrays and declare operations of
that domain.
--
With best regards,
Alexander Korotkov.
Likely we need a patch to rename it in all the places it mentioned.
--
With best regards,
Alexander Korotkov.
-GiST interface functions.
--
With best regards,
Alexander Korotkov.
(Alexander Korotkov)
Actually, we also collect histogram of range lengths. Probably, we can
rephrase it more generally, like Collect and use special statistics for
range types.
--
With best regards,
Alexander Korotkov.
rows=3 loops=1)
Index Cond: (s ~ '[abc]def'::text)
Buffers: shared hit=*497*
Total runtime: 13.786 ms
(7 rows)
--
With best regards,
Alexander Korotkov.
trgm-regexp-gist-optimize.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Tue, Apr 9, 2013 at 9:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Apr 8, 2013 at 9:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I spent the weekend hacking on this, making a number of bug fixes and a
whole lot of cosmetic changes. I
On Mon, Apr 8, 2013 at 9:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
[ trgm-regexp-0.15.patch.gz ]
I spent the weekend hacking on this, making a number of bug fixes and a
whole lot of cosmetic changes. I think there are large parts
if (pg_database_encoding_max_length() 1 bytelen != charlen)
--
With best regards,
Alexander Korotkov.
On Sun, Apr 7, 2013 at 10:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
It's also likely we can change
if (pg_database_encoding_max_length() 1)
into something like
if (pg_database_encoding_max_length() 1 bytelen != charlen)
Hm
On Wed, Apr 3, 2013 at 11:10 AM, Erikjan Rijkers e...@xs4all.nl wrote:
On Tue, April 2, 2013 23:54, Alexander Korotkov wrote:
[trgm-regexp-0.15.patch.gz]
Yes, it does look good now; Attached a list of measurements. Most of the
searches that I put in
that test-program are now speeded up
On Wed, Apr 3, 2013 at 12:36 AM, Erikjan Rijkers e...@xs4all.nl wrote:
On Mon, April 1, 2013 23:15, Alexander Korotkov wrote:
[trgm-regexp-0.14.patch.gz]
Hi Alexander,
Hi Erik!
Something went wrong in this version of the patch: many (most) queries
that were earlier
spectacularly fast
On Mon, Mar 25, 2013 at 2:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Mar 25, 2013 at 1:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Similarly, pushing PG-specific declarations like RE_compile_and_cache()
into regex/regex.h is completely
for
me. I'm going to post reworked version today or tomorrow. I hope we can do
one more review cycle in this CF.
--
With best regards,
Alexander Korotkov.
. In my case it was about
100GB for 100M of records. Therefore index building becomes very expensive
disk-related operation. For the same reason reading a large number of
records from the index is slow too.
I came to Oleg Bartunov, Theodor Sigaev and after a while to Alexander
Korotkov for any
On Sat, Mar 30, 2013 at 3:55 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Hi, Jey!
I remember I've started couple of threads related to cube extension:
Oh, it's a typo. I remember you've started those threads.
http://www.postgresql.org/message-id/4f30616d.3030...@gmail.com
http
On Mon, Mar 25, 2013 at 1:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
Now I have working implemetation of this API. Comments still need rework.
Could you give me any feedback?
I looked at this a little bit, but it's not very far along at all
On Thu, Mar 14, 2013 at 9:40 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.01.2013 09:36, Alexander Korotkov wrote:
On Wed, Jan 23, 2013 at 6:08 AM, Tom Lanet
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.01.2013 09:36, Alexander Korotkov wrote:
On Wed, Jan 23, 2013 at 6:08 AM, Tom Lanet...@sss.pgh.pa.us wrote:
The biggest problem is that I really don't care
lower and upper bounds fall into same histogram bin. In this case
we should subtract lengths of both parts which were cut in the left and in
the right.
--
With best regards,
Alexander Korotkov.
On Wed, Mar 13, 2013 at 11:10 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 01.03.2013 16:22, Alexander Korotkov wrote:
On Tue, Mar 12, 2013 at 8:03 PM, Heikki Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
So, after some hacking, I ended up
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.01.2013 09:36, Alexander Korotkov wrote:
On Wed, Jan 23, 2013 at 6:08 AM, Tom Lanet...@sss.pgh.pa.us wrote:
The biggest problem is that I really don't care
at it post-9.3,
or as rejected if you think the idea won't go anywhere. Please let me
know how you think it looks.
Returned with feedback, definitely.
--
With best regards,
Alexander Korotkov.
On Sun, Mar 3, 2013 at 6:37 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 02/09/2013 05:36 PM, Alexander Korotkov wrote:
Your comments and refactoring looks good for me.
This patch is currently flagged as waiting for author. Have you had a
chance to test and examine Jeff's changes
On Mon, Mar 4, 2013 at 6:53 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 03/04/2013 01:42 AM, Alexander Korotkov wrote:
This patch only adds one more operator to already committed new
opclass. Tests already cover this case. Without patch corresponding
test leads to sequential scan
On Wed, Feb 13, 2013 at 5:55 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Wed, Feb 13, 2013 at 5:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04.01.2013 10:42, Alexander Korotkov wrote:
/*
* Calculate selectivity of operator using histograms of range
lower bounds
proposals to PostgreSQL.
--
With best regards,
Alexander Korotkov.
://www.tokutek.com/2012/12/fractal-tree-indexing-overview/)
and
how TokuDB engine for MySQL is really working nicely with big data.
Hmm, sounds very similar to the GiST buffering build work Alexander
Korotkov did for 9.2. Only the buffers are for B-trees rather than GiST,
and the buffers
in only some of pages is not fair. Now,
it's hard for me to imagine how to generalize it into generic WAL record
type.
--
With best regards,
Alexander Korotkov.
On Wed, Feb 13, 2013 at 5:28 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 04.01.2013 10:42, Alexander Korotkov wrote:
/*
* Calculate selectivity of operator using histograms of range lower
bounds
* and histogram of range lengths.
*/
static double
and refactoring looks good for me.
--
With best regards,
Alexander Korotkov.
calls operator:
CREATE FUNCTION exists_inline (hstore, text) RETURNS bool AS $$ SELECT $1 ?
$2; $$ LANGUAGE sql;
It will inline and use indexes.
--
With best regards,
Alexander Korotkov.
On Sun, Jan 27, 2013 at 10:40 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
Now I'm working on additional comments.
Some comments were added for addKey and addArc(s). I hope they clarify
something.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.12.patch.gz
Description: GNU
On Fri, Jan 25, 2013 at 11:47 AM, Erik Rijkers e...@xs4all.nl wrote:
On Wed, January 23, 2013 08:36, Alexander Korotkov wrote:
Hi!
Some quick answers to the part of notes/issues. I will provide rest of
answers soon.
[...]
trgm-regexp-0.10.patch.gz27 k
Trying to build this I
comparison of CPU time.
--
With best regards,
Alexander Korotkov.
601 - 700 of 1043 matches
Mail list logo
