Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Is't time for 7.2.2 ?
I think we had agreed start of June for 7.2.2.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Tue, 28 May 2002, Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Thank you, Tom. You give me a direction for looking. Attached patch fix
> > the problem with broken state. Please apply it for 7.2.2 and current cvs
>
> Patch applied to current and REL7_2 branch.
Is't time for
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Attached patch fix a bug with creating index. Bug was reported by Chris
>> Hodgson <[EMAIL PROTECTED]>. Please, apply it for 7.2.2 and
>> current CVS.
Patch applied to both branches.
regards, tom lane
---
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Thank you, Tom. You give me a direction for looking. Attached patch fix
> the problem with broken state. Please apply it for 7.2.2 and current cvs
Patch applied to current and REL7_2 branch.
regards, tom lane
-
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Internally splits are doing before calling gistadjscans. All pages
> created by gistSplit will be inserted in the end of parent page.
> GiST's indexes aren't a concurrent there for one call of gistadjscans
> will be sufficiant.
Oh, I see. Thanks.
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>
>>>Hmm, is this patch really correct? Removing the gistadjscans() call
>>>from gistSplit seems wrong to me --- won't that miss reporting splits
>>>on leaf pages? Or does this not matter for some reason?
>>
>
>>gistadjscans() is mo
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Hmm, is this patch really correct? Removing the gistadjscans() call
>> from gistSplit seems wrong to me --- won't that miss reporting splits
>> on leaf pages? Or does this not matter for some reason?
> gistadjscans() is moving to gistlayerinsert. gis
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>
>>>Yeah, but the update case is inserting more entries into the index.
>>>I'm wondering if that causes the index scan's state to get corrupted
>>>so that it misses scanning some entries.
>>>
>
>>Thank you, Tom. You give me a directi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Yeah, but the update case is inserting more entries into the index.
>> I'm wondering if that causes the index scan's state to get corrupted
>> so that it misses scanning some entries.
> Thank you, Tom. You give me a direction for looking. Attached patc
Sorry, forgot a patch...
Teodor Sigaev wrote:
>
>
> Oleg Bartunov wrote:
>
>> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
>> to submit before 7.2.2 release.
>>
>
> Attached patch fix a bug with creating index. Bug was reported by Chris
> Hodgson <[EMAIL PROTECTE
Oleg Bartunov wrote:
> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
> to submit before 7.2.2 release.
>
Attached patch fix a bug with creating index. Bug was reported by Chris Hodgson
<[EMAIL PROTECTED]>. Please, apply it for 7.2.2 and current CVS.
--
Teodor Si
Tested it with current CVS. It works.
Oleg Bartunov wrote:
> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
> to submit before 7.2.2 release.
>
> Oleg
>
> On Sun, 26 May 2002, Teodor Sigaev wrote:
>
>
>>>Yeah, but the update case is inserting more entries into
Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
to submit before 7.2.2 release.
Oleg
On Sun, 26 May 2002, Teodor Sigaev wrote:
> > Yeah, but the update case is inserting more entries into the index.
> > I'm wondering if that causes the index scan's state to get
> Yeah, but the update case is inserting more entries into the index.
> I'm wondering if that causes the index scan's state to get corrupted
> so that it misses scanning some entries. btree has a carefully designed
> algorithm to cope with this, but I have no idea how gist manages it.
Thank you
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Sat, 25 May 2002, Tom Lane wrote:
>> I get the same in current sources (in fact the number of rows updated
>> varies from try to try). Are you sure it's not a problem with the
>> gist index mechanism?
> We'll look once more, but code for select and
On Sat, 25 May 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > test=# update tst set i = i+10 where a && '{3,4}';
> > UPDATE 3267
> > test=# set enable_indexscan=off;
> > SET VARIABLE
> > test=# update tst set i = i+10 where a && '{3,4}';
> > UPDATE 4060
>
> I get the sa
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> test=# update tst set i = i+10 where a && '{3,4}';
> UPDATE 3267
> test=# set enable_indexscan=off;
> SET VARIABLE
> test=# update tst set i = i+10 where a && '{3,4}';
> UPDATE 4060
I get the same in current sources (in fact the number of rows updat
Sorry,
forget to attach file.
Oleg
On Sat, 25 May 2002, Oleg Bartunov wrote:
> Hi,
>
> we've got rather strange problem with updating and GiST indices.
> Below is a test run:
>
> drop table tst;
> create table tst ( a int[], i int );
> copy tst from stdin;
>
> \.
> create index tsti o
Hi,
we've got rather strange problem with updating and GiST indices.
Below is a test run:
drop table tst;
create table tst ( a int[], i int );
copy tst from stdin;
\.
create index tsti on tst using gist (a);
vacuum full analyze;
test=# update tst set i = i+10 where a && '{3,4}';
UPD
19 matches
Mail list logo
