will see, may be it's needed to update the patch
Ibrar Ahmed wrote:
Hi Teodor Sigaev,
I am getting server crash in contrib regression. May be I am doing
something wrong here. Regression diff is attached.
BTW these queries work fine outside the regression.
--
Ibrar Ahmed
Enterpr
Updated patch.
Ibrar Ahmed wrote:
Hi Teodor Sigaev,
I am getting server crash in contrib regression. May be I am doing
something wrong here. Regression diff is attached.
BTW these queries work fine outside the regression.
--
Ibrar Ahmed
EnterpriseDB http://www.enterprisedb.com
be an Assert() instead?
If those can happen during normal operation, then we need a better error
message there.
It should be assert, but assert enabled and disabled code will be different :(.
In both cases, scanGetCandidate() should be called, but in assert enabled c
arnings). I left it with int32 in my version
> of the patch because I thought you may have some reason for using it.
My mistake, thank you for fix
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.siga
.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
rs who runs a huge update should be
satisfied.
I have difficulties in a choice of way. Seems to me, the better will be second
way: if user gets very long time of insertion then (auto)vacuum of his
installation should tweaked.
--
Teodor Sigaev
rgument for any function except gin_numeric_cmp and it
cannot be returned in regular SQL query.
- fix uninstall script for support numeric type.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.
illfactor value, although GIN doesn't use it
for now.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
=./parallel_schedule
...
===
All 120 tests passed.
===
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
good thing IMHO.
Oh, I see. Fixed.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.22.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list
eturned by gin_extract_query_numeric except
providing they as an argument for comparing functions.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
btree_gin-0.9.gz
Description: Unix tar archive
--
Sent
?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
The external indexam use case doesn't impress me either, and Tom seems to agree
(http://archives.postgresql.org/message-id/24006.1221483...@sss.pgh.pa.us).
Just for correctness - there is one external index
http://www.cs.purdue.edu/spgist/
--
Teodor Sigaev
acceptable?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.23.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
implementation, or was it a side-effect of them not supporting recoverability.
GiST concurrent algorithm is based on Log Sequence Number of WAL and that was
the reason to implement WAL (and recoverability) first in GiST.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
7;m afraid for that and will test tomorrow. But statistic from index is exact.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.24.gz
Description: Unix tar archive
--
Sent
sequence :)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
New version is attached
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.25.gz
Description:
#x27;, 'ff', '-', 'bg'. Headline generator knows about that and
it should ignore full hyphen word and show it part by part. It seems to me,
somehow it doesn't ignore full hyphen word - and HLIDSKIP defines types of
lexemes which should be skipped.
--
Teodor Si
Are you planning to submit this as a /contrib module?
I haven't objections to do that, we don't planned that because we know sceptical
relation of community to hints :)
--
Teodor Sigaev E-mail: teo...
dated version with fixed reference counting.
--------
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pg
http://www.sai.msu.su/~megera/wiki/2009-04-03 for more information.
Implementation of red-black tree has several currently unused methods,
but they will be used in next patches.
--
Teodor Sigaev E-mail: teo...@siga
Hi!
patch implements operator class for GiST over points. Supported operations:
point << point
point >> point
point <^ point
point >^ point
point ~= point
point <@ box
box @> point
point <@ polygon
polygon @> point
point <@ circle
uch existing GiST and opclasses,
and could use KNNGiST in other contrib modules
Separate problem is query planning.
1. To use KNNGiST we need to use index scan ! To prevent seqscan on table,
operator >< has extremely high cost.
2. To prevent bitmap index scan, KNN
rator is distance operator, i.e. it's not a member of btree opclass, but
returns non-negative float8 value.
Without index it will be essentially the same as
ORDER BY expression operator expression[ + ..] DESC NULLS LAST
--
Teodor Sigaev E-mail: teo...@si
y, oid, interval, time, date, timestamp and timestamptz
TODO:
- selectivity of ordering operation should be 1.0
- current patch remove support of IndexScanDesc->kill_prior_tuple, it's needed
to restore support if it will not create too big overhead
- documentation
--
Teodor Sigaev
but only for k = 5.
BTW, it's possible to add this feature to plain btree by changing traversal
algorithm, but I'm fill enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http:
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
--
Teodor Sigaev E-mail: t
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
%-), I'm NOT FEEL enough power to do it.
--
Teodor Sigaev E-ma
of index scan
- Sort condition should not be ANDed in explain output
- current patch remove support of IndexScanDesc->kill_prior_tuple, it's needed
to restore support if it will not create too big overhead
- documentation
--
Teodor Sigaev E-mail: t
em with regular
clauses at create_indexscan_plan function. That's solves problems above
Do you suggest to construct that clauses from pathkey representation? And append
constructed clauses to indexquals in create_indexscan_plan?
--
Teodor Sigaev E-ma
Does anyone have ideas what could be the reason for the bug ?
Compression of varlena's header, introduced in 8.3.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.siga
ause)
879 | tender | 'tender' (1 clause)
926 | tender | 'tender' (1 clause)
(13 rows)
So - is this a bug, feature, "feature"?
It's definitely a bug:
select count(*), query from queries group by que
Fixed for CVS HEAD and 8.3, will fix for previous versions too.
Richard Huxton wrote:
Teodor Sigaev wrote:
So - is this a bug, feature, "feature"?
It's definitely a bug:
select count(*), query from queries group by query;
count | query
---+--
3 | 'tend
ALTER TEXT 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 vi
account Clinton'
For another dictionary ( dictionary of number, snowball ) that option is a
meaningless.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing lis
suspiciously long for human input.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
w to catch such bugs in most cases.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
e is equal
if they are binary the same, if not - we should find catalog-defined equal
operation and call it. Binary comparison is only an optimization.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www
example a LIKE condition could be
fully checked against the index entry. Since certain types of indexes
(GIN now, possibly hash in future) are incapable of doing this, there'd
GiST too, because type of storage may be differ from type to be indexed. The
same touches GIN too.
--
Teodor Si
he same.
So, I see three variant:
- add flag in pg_am
- add flag to create operator class and by default it should point to
impossibility to get value from index. At least for GIN and GiST.
--
Teodor Sigaev E-ma
Yeah, just as messy as I feared :-(. My inclination for the first pass
would be to just make it a per-AM flag in pg_am. We could always
complicate matters later.
Agree, and the single existing suitable opclass hasn't operation marked with
RECHECK flag.
--
Teodor S
k) = false;
for (i = 0; i < query->size; i++)
if (item[i].type == QI_VAL)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers ma
is cheap)
RECHECK flag could be removed.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
se
new version of module. Loading dump from previous versions with opclass
definitions is not good action anyway.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers m
interface, old ones will work
with RECHECK. Or we remove RECHECK and force opclasses to use new interface.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mail
st extent interface. Gregory
suggested to split compare method to two methods and I'm intending to do
it.
--
Teodor SigaevEmail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
is good
practice anyway and saved RECHECK will signal about problem earlier.
If user edits dump to remove RECHECK flag then he is an enemy to himself.
So I'm thinking it might be better to switch to the other
preinitialization setting. Comments?
Agreed.
--
Teodor
e in index: it's possible to have
several clusters (groups) with close values in different parts of index.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mail
setext). Method should mark a needed
words/parts/lexemes etc.
4 ts_headline glues fragments into text and returns that.
We need a parser's headline method because only parser knows all about its
lexemes.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
ng or last match.
Now only thesaurus dictionary can work in that mode but nothing forbids to have
another dictionary with phrase recognition.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.siga
in this case too. So each slave just needs to report its own longest
open tx as "open" to master. Yes, it bloats master but no way around it.
Slaves should not report it every time or every transaction. Vacuum on master
will ask them before doing a real work.
--
Teo
ts(prs, query, highlight, num_fragments, max_words);
Suppose, num_fragments < 2?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
x27;s rather simple.
Comments of your code:
1)
+#ifdef PG_MODULE_MAGIC
+PG_MODULE_MAGIC;
+#endif
That isn't needed for compiled-in in core files, it's only needed for modules.
2)
use only /**/ comments, do not use a // (C++ style) comments
--
Teodor Sigaev
y. It should
produce correct tsquery with described above operations.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
should be the same...
On an another note I found that make_tsvector crashes if it receives a
ParsedText with curwords = 0. Specifically uniqueWORD returns curwords
as 1 even when it gets 0 words. I am not sure if this is the desired
behavior.
In all places there is a check bef
e
log-shipping and based on it replication will cause a lot of unobvious
errors/bugs. Is it possible to use catalog version number as WAL version?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.siga
makes needing
to make that work again.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
experiments with exactly the same
conditions.
Interesting for me test is a comparing hlCover with Cover in your patch, i.e.
develop a patch which uses hlCover instead of Cover and compare old patch with
new one.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Hmm, isn't it too complicated? Look, you suggest something like following (Btree
example):
CREATE INDEX idx ON table USING BTREE ( col1, col2 unique);
Is col2 should be unique across the whole index or just for the same col1?
--
Teodor Sigaev
concurrent transactions, and those values can
be variable in size. What other mechanism do we have to share those
variable-sized values among several backends?
In theory, any indexed value in index (for GiST, after compression) should fit
into page at least.
--
Teodor Sigaev
r checking visibility
If you don't store keys in shared memory, then you should consult with heap for
each stored key.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hacke
ext - only for
one call. So, that cache invalidation technique doesn't give any advantage
without rearranging this part.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent vi
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
it's done for GiST and GIN indexes.
--
Teo
nt contains a few query words. Then each
fragment will not contain all query words but will show more occurrences
of query words in the headline. I would like to know what your opinion
on this is.
Agreed.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
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
I went through your code and I have following comments/questions:
one more comment:
7) Hash opclass is absent. Hash opclass framework is used for hash join.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW
ATOR CLASS citext_ops
DEFAULT FOR TYPE mchar USING hash AS
OPERATOR1 = (citext, citext),
FUNCTION1 citext_hash(citext);
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
CREATE FUNCTION citext_hash(*citext*)
DEFAULT FOR TYPE *citext* USING hash AS
Oops, citext of course.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing
*1.885* ms4.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-hackers mailing list (pgsql-hackers@pos
index is binary compatible with current index :)
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
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-hackers mailing list
he bug was dereferencing uninitialized pointer, and postgres dumps core
immediately. And patch does nothing with namespace.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers ma
er structure) and keep reasonable time to search, please, don't be quiet :)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Sorry, lost test sript
BTW, is btree_gin ready to commit by your opinion?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
CREATE OR REPLACE FUNCTION gena()
RETURNS _int4 AS
$$
SELECT array
ry items
found in the cover.
Yeah, but if there is no information then information is absent :), but I agree
with you to change comment
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
greater than non-lossy limit of
tidbitmap. That estimation is a product of indexSelectivity and number of tuples
in pending list.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gi
file.
extractQuery could provide data for each returned key.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
little less confusing if you used two separate
variables rather than using "res" for two purposes.
done
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
btree_gin-0.10.gz
Descrip
direction of making sure autovacuum puts sufficient priority
on this task.
Autovacuum will start if table has GIN index with fastupdate=on and number of
inserted tuple since last vacuum > autovacuum_vacuum_threshold.
--
Teodor Sigaev E-mail: teo
off autovacuum
- set big work_mem
- populate table with GIN index (by needed number of insertion)
- prepare query which will return a lot of results (possibly, with seqscan=off
because cost of scan of pending list grows fast)
- decrease work_mem for at least ten times
- execute query
--
Teodor
Robert Haas wrote:
I believe that user could get GIN's error about work_mem only intentionally:
- turn off autovacuum
Meanwhile, in the other thread, we're having a discussion about people
wanting to do exactly this on a database-wide basis during peak load
hours...
- decrease work_mem for at l
cData structs,
* though not on the data they reference. This is OK since the XLogRecData
* structs are always just temporaries in the calling code.
and I reused once initialized XLogRecData many times in a loop.
--
Teodor Sigaev E-mail: teo...@siga
ce a failures and it will cause very rare
(and GIN could emit WARNING/NOTICE/LOG message). And this solution allows to
remove disabling of indexscan in gincostestimate.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
am.amcanpertuplescan
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
SELECT * FROM foo WHERE t @@ query LIMIT 100
might be a fairly common use case.
It seems to me -
SELECT * FROM foo WHERE t @@ query *ORDER BY rank* LIMIT 100;
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW
lready done for = and <>. Comments?
Agree, will do. Although built-in anyarray operators have ~N^2 behaviour while
intarray's version - only N*log(N)
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW
issue with lossy bitmap.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
concept. Why not call
this GIN_FAST_INSERT_LIST?
Like other defines here - GIN_DATA, not a GIN_DATA_PAGE, GIN_LEAF - not a
GIN_LEAF_TREE_PAGE.
11. ginInsertCleanup. "Inserion" is a typo.
fixed
Unfortunately, I don't understand all of this patch well enough to
give
Right, can't do that on a hot standby server.
Is anywhere applicable hot standby patch? Last version on wiki is 9g and it
can't be applied cleanly.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
#x27;g':A & 'y'^M
I believe that even here parser is working correctly but there is problems in
ispell.
So, although patch fixes the problem, it seems to me patch doesn't do it in
right place. The patch converts multibyte string in non-utf encoding with
C-locale into w
ultibyte encoding. In all other places char2wchar is called only
for non-C locale.
Please, test attached patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
clocale.patch.gz
Description: Unix t
y things are named. For me, this is a deferred or delayed insert
technique to allow batching. I would prefer if everything used one
description, rather than "fast", "pending", "delayed" etc.
Terminology was taken from inverted index technique.
--
Teodor
insert it will work with Hot Standby because there is no any limitation
for number of pages touched or WAL records. There is a problem with cleanup
invoked by gingettuple - slave could not start cleanup process at all and hence
it could emit an error if tidbitmap becomes lossy
be applied. Thanks.
Thank you. Changes are committed up to 8.2
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Say what? What OSes is that?
See attached test program. It tries to convert multibyte russian word in
UTF8 to wide char with C, ru_RU-KOI8-R and ru_RU.UTF-8 locales. The word
contains 6 letters.
FreeBSD 7.2 (short output):
C==
mbstowcs returns 12
ru_RU.KOI8-R=
Hmm well the KOI8 tests unsurprisingly produce random results on
non-KOI8 input. It's pure chance you didn't get EILSEQ.
Because KOI8 is not multibyte encoding.
What errno did you get for the C locale test? On which input
character?Perhaps it's sihnalljng EILSEQ for every byte >0x80 ? That
s
lossy/tbm_max_non_lossy methods because they
become unused
- add new method tbm_add_page(TIDBitmap*, BlockNumber) to add the whole page to
the TIDBitmap.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.siga
).
That seems like a pretty dirty hack. I doubt there's any meaningful
performance advantage from that, but if there is, I think you could use
a statically allocated array instead.
It's easy to un-dirty that hack, but before I'd like to see your comments about
thoughts above.
ine I cannot help but wonder -- where is
gdi->btree.curitem incremented?
At dataPlaceToPage and dataSplitPage called by ginInsertValue().
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
401 - 500 of 830 matches
Mail list logo
