structure.
Please consider applying this to 8.1 (or just let me know and I'll do it
for you).
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast
/tsearch2/wordparser
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
| ''6 \\'' !|'')))');
# insert into tt values ( NULL, E'1(''2''('' 4''(\\|5 | ''6 \\'' !|'')))');
and try dump table and restore:
ERROR: syntax error
CONTEXT: COPY tt, line 5, column tq: '1 ''2'
PS I'm not subscribed to -patches, so I post to -hackers
--
Teodor Sigaev
Patch isn't full, simple test (values are took from regression.diffs):
and try dump table and restore:
ERROR: syntax error
CONTEXT: COPY tt, line 5, column tq: '1 ''2'
Attached cumulative patch fixes problem, but I have some doubts, is it really
needed?
--
Teodor Sigaev
rows=20 loops=1)
Index Cond: ((a 5) AND (a 61000))
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast
,
Agree, but I tried to keep patches independent as possible...
If we will have agreement about ways to resolve, I'll will time to work
further in foreseeable future.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
...
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
bits.
As I remember, I tried to use some thing else but, I've got a lot conflicts
with
AexprConst:
func_name '(' expr_list ')' Sconst
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Ok.
--
Teodor Sigaev
not-null keys doesn't equal to
special hash code?
the patch to do IS NULL only. But if we are going areto support both,
we probably have to have two pg_am flags not one.
GiST isn't effective with single NOT NULL condition ... So, using two flags may
be useful.
--
Teodor Sigaev
using idx on foo (cost=0.00..3475.11 rows=1978
width=8) (never executed)
Index Cond: ((f1 69980) AND (f1 7))
Total runtime: 0.679 ms
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
--
Teodor Sigaev
0.9 doesn't apply cleanly after Peter's changes, so, new version
http://www.sigaev.ru/misc/user_defined_typmod-0.10.gz
Teodor Sigaev wrote:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Is any objections to commit?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
This is not responding to my concern. What you presented was an
Sorry, I see your point now.
Is that test enough? Or I should make more?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
Nice, thanks a lot.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
|
+---+---+---+---+---+---+---+---+
Upper row and left column contain abbreviation of lock modes by the first
characters( AS - ACCESS SHARE )
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
limit ) ? TRUE : FALSE;
#endif
Now consistent function doesn't guarantee exact result, so we should mark '%'
operator in CREATE OPERATOR CLASS with RECHECK option.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW
for index scan.
The attached patch adds a RECHECK too. It seems to work correctly but
the RECHECK COND costs a lot of time :/.
:(
How long is average length of strings in table?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
I think it can be interesting for other flavours of GIN usage. Is
there a way to add the number of entries of the considered indexed
item to the consistent prototype without adding too much overhead and
complexity?
We are thinking about adding extra value, but it's still only thinking.
I don't very like GiST changes: gistgetbitmap will lock/unlock page for every
tuple. It seems to me taht is better to change gistnext function to use some
sort callback, for example. Or have static array for tids in gistgetbitmap...
--
Teodor Sigaev E-mail
))
||
((b-upper = a-upper) (b-lower = a-upper))
) ? true : false;
}
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast
( German, Norwegian ). So, please, test it - we don't know that languages at
all.
2 added recent fixes of contrib/tsearch2
3 fix usage of fopen/fclose
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http
= InvalidStrategy and btree code transforms it to
BTEqualStrategyNumber in _bt_preprocess_keys(), btcostestimate knows that fact too.
GiST doesn't need to transform strategy - it looks at SK_INDEXFINDNULL only.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
switch.
6) pg_dump, psql are changed accordingly.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast)---
TIP 1: if posting
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
http://www.sigaev.ru/misc/tsearch_core-0.58.gz
What is src/backend/utils/tsearch/dict_ispell/parse.h ?
oops - that is unused file after some experiments. Will be removed from patch.
Well, I know what it *is*: it's bison output
for storage in plain memory. NODE is used only
cleanup stop-word placeholders, so it's a binary tree while QTNode represents
t-ary tree (with any number of children).
Thank you for your interesting in tsearch - after recheck of problem pointed
above I'll commit your patch.
--
Teodor Sigaev
.
Some of them might have a natural limit so that you can't force
arbitrarily deep recursions, but check_stack_depth() is cheap enough
that seems best to just stick it into anything that might be a problem.
Agreed.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
Heikki Linnakangas wrote:
Teodor Sigaev wrote:
Ok. Probably easiest to do that by changing the palloc to palloc0 in
parse_tsquery.
and change sizeof to sizeof(QueryItem)
Do you mean the sizeofs in the memcpys in parse_tsquery? You can't
Oops, I meant pallocs in push* function. palloc0
BTW, Teodor, are you intending to review/apply Heikki's tsearch fixes,
or do you want someone else to do it?
I'll do it.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
I am getting confused with the patches and version I have lying around
here... I think I'll have to wait for review of the patches I've posted
this far before I continue hacking.
Sorry for delay - I was busy by another. All your patches are committed with
very small changes.
--
Teodor Sigaev
in memory,
but is more readable in source code. The POSDATAPTR and POSDATALEN
macros are still used, though it would now be more readable to access
the fields in WordEntryPosVector directly.
Did you check it on 64-bit boxes with strict alignment? I remember that was a
headache for me.
--
Teodor
This change introduced a compiler warning. Here is a fix for it.
Remove QueryOperand-istrue flag, it was used only in cover ranking
(ts_rank_cd). Use palloc'ed array in ranking instead of flag.
Thank you, committed
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
to
choose an index scan if your joining column's datatypes do not
match
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcast
reads a lot of tsvectors. It seems to me that ranking test
will be very clear: rank function reads whole tsvector and returns small amount
of data (just a number).
Another testing focus may be a lossy indexes, like a index over polygons.
--
Teodor Sigaev E-mail
1.8MHz, 2Gb with default postgres.conf
8.4 without patch:
Time: 10883,368 ms
8.4 with patch (db was reinited)
Time: 9654,266 ms
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
. It
contains number of bytes between first lexeme in tsvector and needed lexeme.
So, limitation is total length of lexemes plus theirs positional information.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http
SEARCH DICTIONARY foo (...) WITH ( filtering=on|off,
store_original=on|off );
Or per token's type/dictionary pair.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches
dictionary ( dictionary of number, snowball ) that option is a
meaningless.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
is
suspiciously long for human input.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
BTree to eliminate hack around LIKE support.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your
. This support uses outflank ways missing
regular one.
I'm thinking about add new strategy to Btree and allow directly support of
prefix LIKE search. And BTree will scan index while compare method with option
returns true.
--
Teodor Sigaev E-mail: [EMAIL
a TIDBitmap within GIN.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
optimization...
This is still WIP because I haven't touched any contrib code, but
as far as the main backend goes I think it's ready to apply.
Patch to all contrib modules:
http://www.sigaev.ru/misc/contrib.patch.gz
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
Sync with CVS changes and partial match GIN patch. Teach opclass to correct use
of recheck feature.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list
http://www.sigaev.ru/misc/partial_match_gin-0.9.gz
Sync with CVS.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
this option.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
/misc/wildspeed-0.12.tgz
Changes:
- Sync with CVS HEAD
- add third option (StrategyNumber) for comparePartialFn.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW:
http://www.sigaev.ru/
--
Sent via pgsql-patches
There seems to be something broken here: it's acting like prefix search
is on all the time, eg
I'm in sackcloth and ashes...
Fixed and extended regression tests.
http://www.sigaev.ru/misc/tsearch_prefix-0.9.gz
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
exclusive because they touch the same pieces
of code and I'm too lazy to manage several depending patches. I don't see any
problem to join patches to one, but IMHO it will be difficult to review.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
was introduced.
- added documentation
Suppose, patch is ready to review/commit...
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches
in unpredictable moment.
the buffer. To keep that overhead out of the main codepath, we could
make autovacuum to flush the buffers periodically.
Do you mean that GIN sends a smoke signal to the autovacuum launcher process
to ask about vacuum?
--
Teodor Sigaev
more important (or crucial) than
insertion time. Or table stores read-only values.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches
.
Objections?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http
Sync with current CVS HEAD and post in hackers- too because patches- close to
the closing.
http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz
http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
4.994 ms
Index: ~340 s~200 s
Insert: 72 s/166 s/1
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org
compatible with current index :)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription
I looked this over and it looks good in general.
May I think that patch passed review and commit it?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list
/synchronize with multicolumn GIN - both patches
touch the same pieces of code, and I didn't make a single patch to simplify review.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via
Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz
need more review of fast_insert yet? It looked like a number of people
commented on it already.
I still havn't clearness of acceptability for suggested aminsertcleanup
calling.
--
Teodor Sigaev
60 matches
Mail list logo
