uppercased characters from consideration.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.10.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
be better?
Yes. Fixed.
I also renamed get_length_hist_frac to get_length_hist_summ and rewrote
comments about it. Hope it becomes more understandable.
--
With best regards,
Alexander Korotkov.
range_stat-0.10.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing
testcases. Could
you share both database and benchmarking script?
--
With best regards,
Alexander Korotkov.
On Tue, Dec 18, 2012 at 11:45 AM, Erik Rijkers e...@xs4all.nl wrote:
On Tue, December 18, 2012 08:04, Alexander Korotkov wrote:
I ran the same test again: HEAD versus trgm_regex v6, 7 and 9. In v9
there is some gain but also
some regression.
It remains a difficult problem...
If I get
On Tue, Dec 18, 2012 at 12:51 PM, Erik Rijkers e...@xs4all.nl wrote:
On Tue, December 18, 2012 09:45, Alexander Korotkov wrote:
You should use {0,n} to express from 0 to n occurences.
Thanks, but I know that of course. It's a testing program; and in the end
robustness with
unexpected
Hi!
On Mon, Dec 17, 2012 at 12:54 PM, Erik Rijkers e...@xs4all.nl wrote:
On Sun, December 16, 2012 22:25, Alexander Korotkov wrote:
trgm-regexp-0.8.patch.gz 22 k
Hi Alexander,
I gave this a quick try; the patch works when compiled for DEBUG, but
crashes as a
'speed'-compiled binary
On Mon, Dec 17, 2012 at 1:16 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Didn't reproduce it yet. Can you retry it with this line uncommented:
#define TRGM_REGEXP_DEBUG
Then we can see which stage it fails.
Bug is found and fixed in attached patch.
--
With best regards,
Alexander
On Fri, Dec 14, 2012 at 1:34 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, Dec 3, 2012 at 4:31 PM, Alexander Korotkov
aekorot...@gmail.comwrote:
Actually, I generally dislike path matrix for same reasons. But:
1) Output graphs could contain trigrams which are completely useless
, I fixed a compiler warning.
Thanks!
--
With best regards,
Alexander Korotkov.
be fixes in the attached version of
patch. However, it require significant rethinking of comments. Will update
comments and address your questions in a couple of days. Could you recheck
if attached patch really fixes problem you reported?
--
With best regards,
Alexander Korotkov.
range_stat-0.9
Hi!
On Sat, Dec 8, 2012 at 7:05 PM, Andres Freund and...@2ndquadrant.comwrote:
I notice there's no documentation about the new reloption at all?
Thanks for notice! I've added small description to docs in the attached
patch.
--
With best regards,
Alexander Korotkov.
gist_choose_bloat
Hi!
On Sun, Nov 4, 2012 at 11:41 PM, Jeff Davis pg...@j-davis.com wrote:
On Fri, 2012-11-02 at 12:47 +0400, Alexander Korotkov wrote:
Right version of patch is attached.
* In bounds_adjacent, there's no reason to flip the labels back.
Fixed.
* Comment should indicate more explicitly
On Mon, Dec 3, 2012 at 4:31 PM, Alexander Korotkov aekorot...@gmail.comwrote:
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
On Wed, Dec 5, 2012 at 1:56 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 4.12.2012 20:12, Alexander Korotkov wrote:
Hi!
On Sun, Dec 2, 2012 at 5:02 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
I've tried to apply the patch with the current HEAD, but I'm getting
applied on HEAD (because of an assert added to ginRedoCreatePTree), but
that shouldn't be a problem.
Thanks for testing! Patch is rebased with HEAD. The bug you reported was
fixed.
--
With best regards,
Alexander Korotkov.
ginaddinfo.2.patch.gz
Description: GNU Zip compressed data
? If it's so or there are some other
cases which are easy to determine then I'll remove resorderbyonly flag.
--
With best regards,
Alexander Korotkov.
On Tue, Dec 4, 2012 at 9:34 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 18, 2012 at 4:54 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Patch completely changes storage in posting lists and leaf pages of
posting
trees. It uses varbyte encoding for BlockNumber
On Tue, Dec 4, 2012 at 11:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Mon, Dec 3, 2012 at 8:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that, I'm wondering (without having read the patch)
why you need anything more than
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.
--
With best regards,
Alexander Korotkov.
On Fri, Nov 30, 2012 at 6:23 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 30.11.2012 13:20, Alexander Korotkov wrote:
On Thu, Nov 29, 2012 at 5:25 PM, Heikki Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
Would it be safe to simply stop short the depth
On Sat, Dec 1, 2012 at 3:22 PM, Erik Rijkers e...@xs4all.nl wrote:
On Fri, November 30, 2012 12:22, Alexander Korotkov wrote:
Hi!
On Thu, Nov 29, 2012 at 12:58 PM, er e...@xs4all.nl wrote:
On Mon, November 26, 2012 20:49, Alexander Korotkov wrote:
I ran the simple-minded tests
unprocessed branch to immediately finish with matching (this can give us
more false positives but no false negatives).
For overflow of matrix collection, it's safe to do just OR between all the
trigrams.
New version of patch is attached.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.7
Hi!
On Thu, Nov 29, 2012 at 12:58 PM, er e...@xs4all.nl wrote:
On Mon, November 26, 2012 20:49, Alexander Korotkov wrote:
trgm-regexp-0.6.patch.gz
I ran the simple-minded tests against generated data (similar to the ones
I did in January 2012).
The problems of that older version seem
On Fri, Nov 30, 2012 at 3:20 PM, Alexander Korotkov aekorot...@gmail.comwrote:
For depth-first it's not.
Oh, I didn't explained it.
In order to stop graph processing we need to be sure that we put all
outgoing arcs from state or assume that state to be final. In DFS we can be
in the final part
,
Alexander Korotkov.
trgm-regexp-0.6.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
the
information from that presentation included in the patch.
New version of patch is attached. The changes are following:
1) A big comment with high-level description of what is going on.
2) Regression tests.
3) Documetation update.
4) Some more refactoring.
--
With best regards,
Alexander
about another opclass for GiST
focusing on regex and LIKE/ILIKE search?
However, amyway I can create additional patch for current GiST opclass.
--
With best regards,
Alexander Korotkov.
: MAX_RESULT_STATES, MAX_RESULT_ARCS, MAX_RESULT_PATHS. They are
limiting resources usage during regex processing.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.4.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Mon, Nov 19, 2012 at 10:05 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Thu, Nov 15, 2012 at 11:39 PM, Fujii Masao masao.fu...@gmail.comwrote:
Note that we cannot do a partial-match if KEEPONLYALNUM is disabled,
i.e., if query key contains multibyte characters. In this case, byte
Hi!
New version of patch is attached. Changes are following:
1) Right way to convert from pg_wchar to multibyte.
2) Optimization of producing CFNA-like graph on trigrams (produce smaller,
but equivalent, graphs in less time).
3) Comments and refactoring.
--
With best regards,
Alexander
WIP status.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.3.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
and OffsetNumber.
BlockNumber are stored incremental in page. Additionally one bit of
OffsetNumber is reserved for additional information NULL flag. To be able
to find position in leaf data page quickly patch introduces small index in
the end of page.
--
With best regards,
Alexander Korotkov.
ginaddinfo
;
SET
test=# SELECT * FROM test WHERE val LIKE '%aa%';
val
-
aa
aaa
(2 rows)
I think we can use partial match only for singlebyte encodings. Or, at
most, in cases when all alpha-numeric characters are singlebyte (have no
idea how to check this).
--
With best regards,
Alexander Korotkov.
On Sat, Nov 3, 2012 at 4:23 AM, Noah Misch n...@leadboat.com wrote:
On Fri, Nov 02, 2012 at 09:01:17PM +0400, Alexander Korotkov wrote:
On Fri, Nov 2, 2012 at 4:46 PM, Noah Misch n...@leadboat.com wrote:
On Fri, Nov 02, 2012 at 04:05:30PM +0400, Alexander Korotkov wrote:
On Thu, Oct 18
. With BoxStrategyNumberGroup exact calculation is simpler
than gist_box_consistent.
--
With best regards,
Alexander Korotkov.
gistproc_fix-2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Fri, Nov 2, 2012 at 4:46 PM, Noah Misch n...@leadboat.com wrote:
On Fri, Nov 02, 2012 at 04:05:30PM +0400, Alexander Korotkov wrote:
On Thu, Oct 18, 2012 at 11:18 PM, Noah Misch n...@leadboat.com wrote:
--- 1339,1356
*recheck = false
.
In case of text or csv file I don't see why making line number column user
visible is bad.
--
With best regards,
Alexander Korotkov.
On Mon, Oct 1, 2012 at 5:15 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2012-09-04 at 19:21 +0400, Alexander Korotkov wrote:
New version of patch is attached. Parameter randomization was
introduced. It controls whether to randomize choose. Choose algorithm
was rewritten.
Review
..309.25
rows=1000 width=16) (actual time=0.058..0.085 rows=10 loops=1)
Output: x, y
Total runtime: 0.164 ms
(5 rows)
--
With best regards,
Alexander Korotkov.
unused-targets-1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, Sep 11, 2012 at 10:35 AM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2012-09-04 at 19:21 +0400, Alexander Korotkov wrote:
New version of patch is attached. Parameter randomization was
introduced. It controls whether to randomize choose. Choose algorithm
was rewritten.
Do you
On Mon, Aug 27, 2012 at 5:00 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.08.2012 18:51, Heikki Linnakangas wrote:
On 20.08.2012 00:31, Alexander Korotkov wrote:
New version of patch.
* Collect new stakind STATISTIC_KIND_BOUNDS_**HISTOGRAM, which is lower
, but the inclusivities are not. Maybe just pass by value instead?
* Bounds_adjacent is sensitive to the argument order. Can't it just take
bound1 and bound2?
Fixed. Patch is attached.
--
With best regards,
Alexander Korotkov.
range_spgist_adjacent-0.2.patch.gz
Description: GNU Zip compressed data
On Mon, Aug 20, 2012 at 9:13 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Current gistchoose code has a bug. I've started separate thread about it.
http://archives.postgresql.org/pgsql-hackers/2012-08/msg00544.php
Also, it obviously needs more comments.
Current state of patch is more
On Thu, Aug 30, 2012 at 9:11 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 20, 2012 at 12:57 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
I found that code of gistchoose doesn't follow it's logic. Idea of
gistchoose is that first column penalty is more important than
On Mon, Aug 27, 2012 at 5:00 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.08.2012 18:51, Heikki Linnakangas wrote:
On 20.08.2012 00:31, Alexander Korotkov wrote:
New version of patch.
* Collect new stakind STATISTIC_KIND_BOUNDS_**HISTOGRAM, which is lower
no
optimal solution for all the cases. We could introduce user-visible option
which enables or disables randomization. However, default value of this
option is another question.
Also, I think you should use random() rather than rand().
Thanks, will fix.
--
With best regards,
Alexander
On Thu, Aug 16, 2012 at 4:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15.08.2012 11:34, Alexander Korotkov wrote:
Ok, we've to decide if we need standard histogram. In some cases it can
be used for more accurate estimation of and operators.
But I think
check in order to make it more clear.
--
With best regards,
Alexander Korotkov.
range_spgist_adjacent-0.1.patch
Description: Binary 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 Tue, Aug 14, 2012 at 7:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.08.2012 09:45, Alexander Korotkov wrote:
After fixing few more bugs, I've a version with much more reasonable
accuracy.
Great! One little thing just occurred to me:
You're relying
be used for more accurate estimation of and operators.
But I think it is not so important. So, we can replace standard histogram
with histograms of lower and upper bounds?
--
With best regards,
Alexander Korotkov.
On Mon, Aug 13, 2012 at 1:11 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Thu, Aug 9, 2012 at 12:44 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
My conclusion is so, that current errors are probably ok for selectivity
estimation. But taking into attention that generated
On Thu, Aug 9, 2012 at 12:44 AM, Alexander Korotkov aekorot...@gmail.comwrote:
My conclusion is so, that current errors are probably ok for selectivity
estimation. But taking into attention that generated datasets ideally fits
assumptions of estimation, there could be room for improvement
New revision of patch with two fixes:
1) Check if histogram bin width is zero in get_position.
2) Check statsTuple is valid tuple in rangecontsel.
--
With best regards,
Alexander Korotkov.
range_stat-0.3.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list
?
--
With best regards,
Alexander Korotkov.
range_spgist_quad-0.7.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 Mon, Aug 6, 2012 at 6:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 04.08.2012 12:31, Alexander Korotkov wrote:
Hackers,
attached patch is for collecting statistics and selectivity estimation for
ranges.
In order to make our estimations accurate for every
On Thu, Jul 19, 2012 at 12:22 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.07.2012 02:00, Alexander Korotkov wrote:
On Thu, Jul 12, 2012 at 10:29 AM, Heikki Linnakangas
heikki.linnakangas@**enterprisedb.comheikki.linnakan...@enterprisedb.com
wrote:
Thanks. Can
.
Agree, I think we should stay at quad tree implemetation.
--
With best regards,
Alexander Korotkov.
, then the first byte of
multibyte must be 0x9c. If the second byte of wchar is in range of
0xf5 to 0xfe, then the first byte of multibyte must be 0x9d.
Should I intergrate these code changes into my patch? Or we would like to
commit them first?
--
With best regards,
Alexander Korotkov.
by thoughts. I
think if he'll verify it in this thread, it should be enough for review of
few lines bugfix.
If we say about bugfix I provided for backpatch, it need more detailed
review. I was a miss that I didn't add it to current commitfest, will add
it to the next one.
--
With best regards,
Alexander
On Tue, Jul 3, 2012 at 10:51 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-07-02 at 23:47 -0700, Jeff Davis wrote:
On Thu, 2012-06-14 at 02:56 +0400, Alexander Korotkov wrote:
Hackers,
attached patch implements quad-tree on ranges. Some performance
results in comparison
On Mon, Jul 2, 2012 at 8:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
MULE also looks problematic. The code that you've written isn't
symmetric with the opposite conversion, unlike what you did in all
other
On Tue, Jul 3, 2012 at 12:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 2, 2012 at 4:33 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
On Mon, Jul 2, 2012 at 8:12 PM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Jul 1, 2012 at 5:11 AM, Alexander Korotkov
aekorot
to make it
more transparent.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.4.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
doing original changes. This it probably ok. But, we
could do some heuristics: detect that sequential scan is cheaper because of
large amount of updates or deletes in one table.
--
With best regards,
Alexander Korotkov.
On Sun, Jul 1, 2012 at 3:11 PM, Alexander Korotkov aekorot...@gmail.comwrote:
1) Patches don't apply cleanly to head. So I used commit
bed88fceac04042f0105eb22a018a4f91d64400d as the base for patches, then all
the patches close to this apply cleanly. Regression tests pass OK, but it
seems
On Wed, Feb 22, 2012 at 5:56 PM, Alexander Korotkov aekorot...@gmail.comwrote:
Attached patch fixes GiST behaviour without altering operators behaviour.
I think we definitely should apply this patch before 9.2 release, because
it is a bug fix. Otherwise people will continue produce incorrect
On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 14.06.2012 01:56, Alexander Korotkov wrote:
Hackers,
attached patch implements quad-tree on ranges. Some performance results in
comparison with current GiST indexing.
@@ -788,7 +774,7
On Thu, Jun 14, 2012 at 2:56 AM, Alexander Korotkov aekorot...@gmail.comwrote:
attached patch implements quad-tree on ranges. Some performance results in
comparison with current GiST indexing.
Index creation is slightly slower. Probably, it need some investigation.
Search queries on SP-GiST
that chances.
Obviously, it makes insertion more expensive. I need some more benchmarks
to measure it. Probably, we would need a user-visible option for cheaper
insert or less bloat.
--
With best regards,
Alexander Korotkov.
gist_choose_bloat-0.1.patch
Description: Binary data
--
Sent via
@ '[2011-08-10,2011-12-31)'::daterange)
Buffers: shared hit=3093 read=1034
Total runtime: 54.288 ms
(7 rows)
--
With best regards,
Alexander Korotkov.
range_spgist_quad-0.2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Tue, Jun 5, 2012 at 2:00 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Alexander, do you still have
On Mon, May 28, 2012 at 1:46 AM, Alexander Korotkov aekorot...@gmail.comwrote:
On Sat, May 26, 2012 at 12:33 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Alexander, do you still have the test environments and data lying around
that you used for GiST buffering testing
of average tuple size?
--
With best regards,
Alexander Korotkov.
GiST index build, backend was frequently crashed. After recovery
partially built index file was remain. Do we have some tool to detect such
dead files? If not, probably we need some?
--
With best regards,
Alexander Korotkov.
to understand without reverse engeneering it from code.
--
With best regards,
Alexander Korotkov.
dubious to be comparing to a block count
even disregarding the power function.
In this test we use avgIndexTuplesPerPage as estimate for number of child
index pages of one page. I think we can assume it to have blocks unit.
--
With best regards,
Alexander Korotkov.
On Wed, May 30, 2012 at 12:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Tue, May 29, 2012 at 11:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, is the first test involving
effective_cache_size bulletproof either
buffering testing last summer? Could you rerun some
of those tests with this patch?
I think I can restore test environment and data. Will rerun tests soon.
--
With best regards,
Alexander Korotkov.
, then they are LC2.
If LB is in 0xf0 - 0xff range, then they are LCPRV2.
Thanks. I rewrote inverse conversion from pg_wchar to mule. New version of
patch is attached.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
and
charsets, see pg_wchar.h.
Thanks for your comments. They clarify a lot.
But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
Isn't it possible for them to produce same pg_wchar?
--
With best regards,
Alexander Korotkov.
On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
Improve GiST box and point index performance by producing better trees
with
less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas
to occur after creating GISTBufferingInsertStack
but before split of A. The question is how to find this copy from C, hash?
--
With best regards,
Alexander Korotkov.
changes in this function which make inverse conversion possible.
--
With best regards,
Alexander Korotkov.
gist (t collate C)
WITH (fillfactor=10);
I'll continue debugging that, but it seems to be another, unrelated, bug.
Thanks for debugging and fixing that. I'm going to take a look on the
remaining bug.
--
With best regards,
Alexander Korotkov.
, the
question arises if we're going to measure ratio in tuples count or in
tuples size. Ratio in tuples size seems to be more desirable while ratio in
tuples count seems to be easier for user picksplit to follow.
--
With best regards,
Alexander Korotkov.
Improve GiST box and point index performance by producing better trees
with less memory allocation overhead (Alexander Korotkov, Heikki
Linnakangas, Kevin Grittner)
Is this note about following two commits?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h
On Wed, May 2, 2012 at 4:50 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 1, 2012 at 6:02 PM, Alexander Korotkov aekorot...@gmail.com
wrote:
Right. When number of trigrams is big, it is slow to scan posting list of
all of them. The solution is this case is to exclude most
On Wed, May 2, 2012 at 5:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 2, 2012 at 9:35 AM, Alexander Korotkov aekorot...@gmail.com
wrote:
Imagine we've two queries:
1) SELECT * FROM tbl WHERE col LIKE '%abcd%';
2) SELECT * FROM tbl WHERE col LIKE '%abcdefghijk
such datasets?
Also, I did some optimizations in algorithm. Automaton analysis stage
should become less CPU and memory consuming. I'll publish new version soon.
--
With best regards,
Alexander Korotkov.
such decision, but it doesn't seem to be feasible
to get it using current GIN interface.
Probably you have some comments on idea of conversion from pg_wchar to
multibyte? Is it acceptable at all?
--
With best regards,
Alexander Korotkov.
in the same query.
--
With best regards,
Alexander Korotkov.
.
--
With best regards,
Alexander Korotkov.
wchar2mb-0.1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
which looks like extension of Jeff Davis proposal to
the multidimensional case. It is Plane Sweep and External Plane Sweep
methods. However, it might use sophisticated data structures for the
sweep. And I believe it should use it for good performance.
--
With best regards,
Alexander Korotkov.
On Tue, Apr 17, 2012 at 12:12 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-04-16 at 16:22 +0400, Alexander Korotkov wrote:
There is a good overview article about spatial joins.
http://www.cs.umd.edu/users/hjs/pubs/jacoxtods07.pdf
Thank you, that's exactly the kind of overview I
On Mon, Mar 12, 2012 at 3:50 PM, Alexander Korotkov aekorot...@gmail.comwrote:
I believe that attached version of patch can be backpatched. It fixes this
problem without altering of index building procedure. It just makes checks
in internal pages softener enough to compensate effect
On Thu, Mar 8, 2012 at 4:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alexander Korotkov aekorot...@gmail.com writes:
True. If (max count - min count + 1) is small, enumerating of frequencies
is both more compact and more precise representation. Simultaneously,
if (max count - min count + 1
I believe that attached version of patch can be backpatched. It fixes this
problem without altering of index building procedure. It just makes checks
in internal pages softener enough to compensate effect of gist_box_same
implementation.
--
With best regards,
Alexander Korotkov.
*** a/src
statkind and statistics slot. Probably, you've
better ideas?
--
With best regards,
Alexander Korotkov.
array of
unique DEC and it's frequency.
--
With best regards,
Alexander Korotkov.
*** a/src/backend/utils/adt/array_typanalyze.c
--- b/src/backend/utils/adt/array_typanalyze.c
***
*** 581,587 compute_array_stats(VacAttrStats *stats, AnalyzeAttrFetchFunc fetchfunc
case rough estimate is quite accurate. But in most
part of cases it behaves really bad. It is why I started to invent
calc_distr and etc. So, I think return DEFAULT_CONTAIN_SEL is OK unless
we've some better ideas.
--
With best regards,
Alexander Korotkov.
701 - 800 of 1043 matches
Mail list logo
