list.
Thanks,
Daniel
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---
ly be less amount of
study (and this is what GiST and SP-GiST is all about if I correctly
understand ).
Please let me know your opinions regarding to this.
Thanks
Ramy
Regards,
Oleg
_
Oleg Bartunov, sci.resea
as soon
as they support different operations. I don't know if it's possible
to have them for the same operation but for different conditions.
Thanks
Ramy
-Original Message-
From: Oleg Bartunov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 10, 2004 12:35 AM
To: Ramy M. Hass
s in advance,
Patrick
On Tuesday 09 November 2004 22:08, Oleg Bartunov wrote:
Oleg Bartunov <[EMAIL PROTECTED]>
Daniel,
concurrency is a big issue of current implementation of GiST.
But it should don't bite you for READ ops !
-hackers mailing list is a very relevant mailing list for Gi
, but this is what I see. I would
appreciate your opinions regarding to this design issue.
Teodor is rather busy right now, but he certainly knows better GiST
internals,
so we'll wait his comments.
Thanks
Ramy
-Original Message-----
From: Oleg Bartunov [mailto:[EMAIL PROTECTED]
Sent:
rs/F/Fasch,_Johann_Friedrich
Kind regards
John
-Original Message-
From: Oleg Bartunov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 11, 2004 8:48 PM
To: John Hansen
Cc: Teodor Sigaev; Pgsql Hackers
Subject: Re: ltree PostgreSQL Module
John,
On Thu, 11 Nov 2004, John Hansen wrote:
Hell
help you.
Kind Regards,
John Hansen
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~m
Referencia/Bibliotecas/Nacionales','/','.'));
ERROR: syntax error at position 14 near "?"
I've also found that topics contain , as in the DMOZ Topic:
Top/Arts/Music/Composition/Composers/F/Fasch,_Johann_Friedrich
Kind regards
John
-Original Message-
rk on ltree now.
... John
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-
ver
3. Links to companies offering commercial support
This way we'll support local postgresql community and give equal chance
for commercial companies.
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of
-Josh
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone
On Fri, 12 Nov 2004, Marc G. Fournier wrote:
Please join [EMAIL PROTECTED] where this has been being reviewed,
critisized and discussed for the past month or so :(
just joined :)
On Fri, 12 Nov 2004, Oleg Bartunov wrote:
Josh,
what is a status of press release
http://cvs.pgfoundry.org/cgi-bin
resql community and give equal chance
for commercial companies.
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PRO
t to be fixed anyway.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Regards,
Oleg
_____
Oleg Bart
ut
updating a large index covering all the indexes values
in the column. Is it conceivable to create such an
index "cluster"?
2. Does someone know of interesting documentation (perhaps
in the form of interesting code comments) which I should
read, as a basis for creating a non-standard
On Fri, 19 Nov 2004, Troels Arvin wrote:
Hello Oleg,
On Fri, 2004-11-19 at 15:35 +0300, Oleg Bartunov wrote:
your project looks very attractive.
Thanks.
In principle, suffix array should be implemented using GiST framework.
But in a previous conversation between the two of us, you wrote that the
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of
traut" <[EMAIL PROTECTED]>
Sent: January 06, 2005 3:48 AM
Am Mittwoch, 5. Januar 2005 05:38 schrieb Oleg Bartunov:
Serguei, I have translations (I didn't touch libpq, psql in work,
other files seems complete) available from
http://www.sai.msu.su/~megera/oddmuse/
Let me know when you ha
bly require initdb, at least for those as are using tsearch2.
Thoughts anyone?
regards, tom lane
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical I
Hi there,
I'm willing to help anybody to prepare tutorials or paper about
full text search in postgresql and other our contrib modules.
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of Ast
ictionary.
Chris
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-
iew.com/go/osdn_nl
___
OpenFTS-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openfts-general
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, host
TAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 67.12s/228.84u sec elapsed 1010.20 sec.
INFO: "usno": removed 2796013 row versions in 17809 pages
DETAIL: CPU 1.50s/1.82u sec elapsed 19.98 sec.
Regards,
Oleg
___
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
Nothing strange about it: that's how
On Fri, 28 Jan 2005, Oleg Bartunov wrote:
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
On Fri, 28 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Memory growth stoped at 1.8Gb
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
20458 postgres 15 0 1902m 503m 204m D 5.9 49.7 13:59.61 postmaster
Index-related memory leak maybe? What are the indexes on this
wsdb > vacuum-wsdb.log 2>&1&
-rw-r--r--1 postgres postgres48784 Jan 28 15:03 vacuum-wsdb.log
Is there something I could do ?
Oleg
On Fri, 28 Jan 2005, Oleg Bartunov wrote:
On Fri, 28 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Memory growth stoped at 1.8Gb
PID USE
-
ra | real |
dec| real |
bmag | real |
rmag | real |
ipix | bigint |
Indexes:
"ipix_ind" btree (ipix)
"radec_idx1" btree (ra, "dec")
Regards,
Oleg
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
I tried run 'vacuumdb -v -z -f wsdb > vacuum-wsdb.log 2>&1&'
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
On Sun, 30 Jan 2005, Tom Lane wrote:
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it ... or did you change?
Yes, first time
On Sun, 30 Jan 2005, Oleg Bartunov wrote:
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
On Sun, 30 Jan 2005, Tom Lane wrote:
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it
On Sun, 30 Jan 2005, Oleg Bartunov wrote:
Seems, postmaster eats expected amount of memory now ! Will see how long
it will proceeded. Probably, my case should be documented somewhere.
just to inform - vacuum took almost 48 hours !
Another possibility is to use CLUSTER or a rewriting ALTER TABLE
On Tue, 1 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I see that pgsql_tmp/ contains files, looks like clustered table.
What postmaster is doing if disk usage doesn't changed ?
Most likely doing a disk-based merge sort ...
just interesting - multiway, in-place or just place merge
On Tue, 1 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I see that pgsql_tmp/ contains files, looks like clustered table.
What postmaster is doing if disk usage doesn't changed ?
Most likely doing a disk-based merge sort ...
so, it uses 'work_mem' as a buffer ?
80fe8b3 in BackendStartup ()
#20 0x80fdb7d in ServerLoop ()
#21 0x80fd750 in PostmasterMain ()
#22 0x80dd93e in main ()
#23 0x2ab8c9cb in ?? ()
(gdb)
Would you have any advice for me?
Many thanks,
-Robin Chauhan
---(end of broadcast)---
TIP 1: subs
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +00
On Tue, 8 Feb 2005, Marc G. Fournier wrote:
On Tue, 8 Feb 2005, Oleg Bartunov wrote:
Marc,
On Tue, 8 Feb 2005, Marc G. Fournier wrote:
I believe that this is what Oleg et al tap into with the tsearch2 stuff,
no? I have someone asking me about it, and want to make sure that I'm
telling hi
I was asked to give a lectures (a whole day) about PostgreSQL in Moscow, Russia.
Since I'm new to such kind of activity I'n looking for any presentations,
curlliculum for starting.
Regards,
Oleg
_
Ole
.su/~megera/postgres/gist/tsearch/V2/expand_query_8.0.patch.gz
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83
terns, a larger sample allows them to be "less wrong" enough to give a
better hint to the planner.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Regards,
Oleg
_
2617283 | 2417279 |1
did I miss something ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.ms
at 11:48:54PM +0300, Oleg Bartunov wrote:
Hi there,
is't possible to make table to be inherited from another table in case
both tables already exist. I tried to insert record to pg_inherits,
but it doesn't helped.
openfts=# select * from pg_inherits;
inhrelid | inhparent
On Wed, 16 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I know this. I need to create inheritance for already created tables.
There is no way to do this using alter table, so I tried to
define it by hand :)
Did you remember to set relhassubclass for the parent table?
AFAIR, all that you really
Marc,
Below is a message I just received and I'm wondering what's a problem
of such delay ? 5 days is too much :)
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg As
On Mon, 21 Feb 2005, Marc G. Fournier wrote:
On Mon, 21 Feb 2005, Oleg Bartunov wrote:
Marc,
Below is a message I just received and I'm wondering what's a problem
of such delay ? 5 days is too much :)
It was posted by someone not subscribed to the mailing list, and had to be
manually a
On Mon, 28 Feb 2005, Richard Huxton wrote:
Oleg Bartunov wrote:
Hi there,
what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ?
qq=# create table t1( id serial);
NOTICE: CREATE TABLE will create implicit sequence "t1_id_seq" for
"serial" colum
-TABLES
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end o
On Mon, 28 Feb 2005, Stephan Szabo wrote:
On Mon, 28 Feb 2005, Oleg Bartunov wrote:
what's wrong to use SERIAL as FK without explicit PRIMARY KEY or UNIQUE ?
Serial isn't enough to guarantee uniqueness as required by foreign keys.
you're certainly right !
Regards,
I'm wondering,
is there any sense to cluster table using two-column index ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (R
s clustered hit
ratio is very good and execution time is < 0.5s.
Regards,
Oleg
_____
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai
Oleg
PS.
forget to mention that collation works fine
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
On Sat, 16 Sep 2000, Tom Lane wrote:
> Date: Sat, 16 Sep 2000 11:23:33 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [HACKERS] broken locale in 7.0.2 without multibyte sup
nt Peter's changes could cause the problem
Regards,
Oleg
On Sat, 16 Sep 2000, Tom Lane wrote:
> Date: Sat, 16 Sep 2000 13:21:20 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>, Peter Eisentraut <[EMAIL PROTECTED]
nt use any
"-funsigned-chars" like options !
Regards,
Oleg
On Sun, 17 Sep 2000, Tom Lane wrote:
> Date: Sun, 17 Sep 2000 13:48:37 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Peter Eisentraut <[EMAIL PROTECTED]>
> Cc: Oleg Bartunov <[EMA
ions
Tatsuo, am I right and what critical sections in backend/regex/regcomp.c ?
Regards,
Oleg
> --
> Tatsuo Ishii
>
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institu
Also, GiST index is faster for create/update operations. I really hope we will
improve jsonb indexing in the next one-two releases. For now I'd suggest people
index expressional indexes to index just interesting keys or use GiST.
On Wed, Mar 12, 2014 at 5:15 PM, Tomas Vondra wrote:
> On 12 Březen
On Thu, Mar 13, 2014 at 12:10 AM, Peter Geoghegan wrote:
> On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov wrote:
>> Also, GiST index is faster for create/update operations. I really hope we
>> will
>> improve jsonb indexing in the next one-two releases. For now I'd s
On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov
wrote:
> On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark wrote:
>>
>> Well these are just normal gin and gist indexes. If we want to come up
>> with new index operator classess we can still do that and keep the old
>> ones if necessary. Even that se
VODKA index will have no lenght limitation.
On Fri, Mar 14, 2014 at 3:07 PM, Tomas Vondra wrote:
> On 13 Březen 2014, 23:39, Peter Geoghegan wrote:
>> On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark wrote:
>>> It does sound like the main question here is which opclass should be
>>> the default. From
9.5 may too optimistic :)
On Fri, Mar 14, 2014 at 11:18 PM, Josh Berkus wrote:
> On 03/14/2014 04:52 AM, Oleg Bartunov wrote:
>> VODKA index will have no lenght limitation.
>
> Yeah, so I think we go with what we have, and tell people "if you're
> hitting these length
Alexander will take a look on TriConsistent function.
On Mon, Mar 17, 2014 at 9:48 PM, Andrew Dunstan wrote:
>
> On 03/16/2014 04:10 AM, Peter Geoghegan wrote:
>>
>> On Thu, Mar 13, 2014 at 2:00 PM, Andrew Dunstan
>> wrote:
>>>
>>> I'll be travelling a good bit of tomorrow (Friday), but I hope P
It's easy to add support of other operations to hash_ops, so it will
be on par with default GIN opclass, at the price of bigger size. We
can add it later to contrib/jsonbext.
I'm mostly worrying about changing semantics of scalar.
On Sun, Mar 23, 2014 at 4:27 AM, Peter Geoghegan wrote:
> On Sa
Very interesting idea, I'd think about optionally add similarity hinting
support to psql tab. With, say, 80% of similarity matching, it
shouldn't be very annoying. For interactive usage there is no risk of
slowdown.
On Mar 27, 2014 11:11 PM, "Peter Geoghegan" wrote:
> With the addition of
Hi there,
I'm wondering if we should follow all js equility rules as
nicely visualized in
http://strilanc.com/visualization/2014/03/27/Better-JS-Equality-Table.html
Oleg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Sure, we don't follow. I mean should we add to documentation
such matrices.
Oleg
On Thu, Apr 3, 2014 at 11:32 AM, Oleg Bartunov wrote:
> Hi there,
>
> I'm wondering if we should follow all js equility rules as
> nicely visualized in
> http://strilanc.com/visualiza
Well, we don't supported Infinity and NaN in json(b), as well as Json
standard :)
Now we need a script, which generated nice html table.
On Thu, Apr 3, 2014 at 12:40 PM, Yeb Havinga wrote:
> On 2014-04-03 09:40, Oleg Bartunov wrote:
>>
>> Sure, we don't follow
We are working to avoid this limitation.
On Tue, Apr 8, 2014 at 10:54 PM, Peter Geoghegan wrote:
> On Mon, Apr 7, 2014 at 8:29 PM, Michael Paquier
> wrote:
>> Documentation of jsonb tells that jsonb documents should be kept at a
>> reasonable size to reduce lock contention, but there is no menti
On Wed, Apr 9, 2014 at 1:48 AM, Tom Lane wrote:
> Oleg Bartunov writes:
>> We are working to avoid this limitation.
>
> What do you mean by that ... do you see it as something that could be
> fixed quickly, or is this a long-term improvement project?
Unfortunately, It's
I found a bit confusing, when planning time is greater total time, so
+1 for execution time.
On Thu, Apr 17, 2014 at 3:35 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Where are we on this? I still see:
>
>> test=> EXPLAIN ANALYZE SELECT 1;
>>Q
Bruce,
you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
for GIN. Something like
"Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
which competes with MongoDB performance in contains operator".
Here is a link to discussion -
http://www.postgresql.org/message-i
I agree, no mongo :)
On Sun, May 4, 2014 at 8:47 PM, Magnus Hagander wrote:
>
> On Sun, May 4, 2014 at 4:06 PM, Oleg Bartunov wrote:
>>
>> Bruce,
>>
>> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
>> for GIN. Something like
>>
FYI,
http://obartunov.livejournal.com/178495.html
This is hash based gin opclass for hstore with all operators support.
It's pity we had no time to do the same for jsonb, but we may include
it and couple of other opclasses to contrib/jsonx.
Oleg
On Wed, May 7, 2014 at 12:18 AM, Peter Geoghegan
+1
but bit confused with json instead of jsonb
On Sun, May 11, 2014 at 1:00 AM, Andrew Dunstan wrote:
>
> On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
>>
>>
>>
>> The main difference between the two opclasses from a user's standpoint is
>> not whether they hash or not. The big difference is
The patch really improves access performance to jsonb. On the
delicious bookmarks I got 5 times better performance.Now jsonb
outperforms json on simple access (slide 12 of pgcon presentation) by
103 times !
Oleg
On Fri, May 30, 2014 at 9:35 AM, Teodor Sigaev wrote:
> Hi!
>
> jsonb operators ->
Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
On Fri, Jun 6, 2014 at 4:34 AM, David E. Wheeler wrote:
> On Jun 5, 2014, at 5:25 PM, Andrew Dunstan wrote:
>
>> My understanding is that it's meant to be analogous to tsquery.
>>
>> At first glance, JsonPath doesn't seem
901 - 976 of 976 matches
Mail list logo