But I don't understand this comment:
+ /*
+* While we delete only one tuple at once we could mix calls
+* PageIndexTupleDelete() here and PageIndexMultiDelete() in
+* gistRedoPageUpdateRecord()
+*/
Does this mean:
Sin
On Wed, Sep 16, 2015 at 8:36 AM, Teodor Sigaev wrote:
> But It seems to me that it would be better to rewrite all mentions of
>> TupleDelete to MultiDelete in gist code.
>>
>
> Sure. Patch is attached, and it changes WAL format, so be carefull with
> testing.
> Please, have a look.
>
> Also in at
But It seems to me that it would be better to rewrite all mentions of
TupleDelete to MultiDelete in gist code.
Sure. Patch is attached, and it changes WAL format, so be carefull with testing.
Please, have a look.
Also in attach scripts reproduce bug from Jeff's report:
g.pl - creates and fills
16.09.2015 07:30, Jeff Janes:
The commit of this patch seems to have created a bug in which updated
tuples can disappear from the index, while remaining in the table.
It looks like the bug depends on going through a crash-recovery cycle,
but I am not sure of that yet.
I've looked through
On Tue, Sep 8, 2015 at 2:35 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Fixed patch is attached.
>
>
The commit of this patch seems to have created a bug in which updated
tuples can disappear from the index, while remaining in the table.
It looks like the bug depends on g
On 8 September 2015 at 22:35, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Fixed patch is attached.
>
> 08.09.2015 13:47, Teodor Sigaev:
>
>> BTW, I slightly modify your test to provide more stable results.
>>
>
> Thank you, I tried it, Results are nearly the same.
>
> Without
Fixed patch is attached.
08.09.2015 13:47, Teodor Sigaev:
BTW, I slightly modify your test to provide more stable results.
Thank you, I tried it, Results are nearly the same.
Without microvacuum
Time: 312,955 ms
Time: 264,597 ms
Time: 243,286 ms
Time: 243,679 ms
With microvacuum:
Time: 354,
BTW, I slightly modify your test to provide more stable results.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
drop table test;
CREATE TABLE test (box box);
alter table test set (autovacu
Something goes wrong...
gist.c:1465:5: warning: unused variable 'minoff' [-Wunused-variable]
minoff,
gistget.c:37:1: warning: unused function 'gistkillitems' [-Wunused-function]
gistkillitems(IndexScanDesc scan)
Without microvacuum. All 'select' queries are execu
04.09.2015 15:11, Teodor Sigaev:
Some notices
1 gistvacuumpage():
OffsetNumber deletable[MaxOffsetNumber];
Seems, MaxOffsetNumber is too much, MaxIndexTuplesPerPage is enough
Fixed.
2 Loop in gistkillitems() for searching heap pointer. It seems to me that
it could be a performance prob
Some notices
1 gistvacuumpage():
OffsetNumber deletable[MaxOffsetNumber];
Seems, MaxOffsetNumber is too much, MaxIndexTuplesPerPage is enough
2 Loop in gistkillitems() for searching heap pointer. It seems to me that
it could be a performance problem. To fix it, it's needed to remember inde
Hi,
I don't know too much about gist, but did a quick read through. Mostly
spotting some stylistic issues. Please fix those making it easier for
the next reviewer.
Thank you for review! All mentioned issues are fixed.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
T
Hi,
I don't know too much about gist, but did a quick read through. Mostly
spotting some stylistic issues. Please fix those making it easier for
the next reviewer.
> *** a/src/backend/access/gist/gist.c
> --- b/src/backend/access/gist/gist.c
> ***
> *** 36,42 static bool gistinse
On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
1) Test and results are in attachments. Everything seems to work
as expected.
2) I dropped these notices. It was done only for debug purposes.
Updated patch is attached.
3)
On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 1) Test and results are in attachments. Everything seems to work as
> expected.
> 2) I dropped these notices. It was done only for debug purposes. Updated
> patch is attached.
> 3) fixed
>
Good! Anothe
30.07.2015 16:33, Alexander Korotkov пишет:
Hi!
On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova
mailto:lubennikov...@gmail.com>> wrote:
I have written microvacuum support for gist access method.
Briefly microvacuum includes two steps:
1. When search tells us that the tupl
On 7/30/15 7:33 AM, Alexander Korotkov wrote:
2) Generating notices for every dead tuple would be too noisy. I suggest
to replace notice with one of debug levels.
+ elog(NOTICE, "gistkillitems. Mark Item Dead offnum %hd, blkno %d",
offnum, BufferGetBlockNumber(buffer));
Even that seems like pr
Hi!
On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova <
lubennikov...@gmail.com> wrote:
> I have written microvacuum support for gist access method.
> Briefly microvacuum includes two steps:
> 1. When search tells us that the tuple is invisible to all transactions it
> is marked LP_DEAD and
Hi,
I have written microvacuum support for gist access method.
Briefly microvacuum includes two steps:
1. When search tells us that the tuple is invisible to all transactions it
is marked LP_DEAD and page is marked as "has dead tuples",
2. Then, when insert touches full page which has dead tuples
19 matches
Mail list logo
