On Mon, 18 Nov 2024 at 16:34, Andrey M. Borodin wrote:
>
>
>
> > On 2 Nov 2024, at 02:36, Kirill Reshke wrote:
> >
> > I noticed CI failure for this patch. This does not look like a flap.
>
> Seems like vacuum did not start index cleanup. I’ve added "index_cleanup on".
> Thanks!
>
>
> Best regard
> On 2 Nov 2024, at 02:36, Kirill Reshke wrote:
>
> I noticed CI failure for this patch. This does not look like a flap.
Seems like vacuum did not start index cleanup. I’ve added "index_cleanup on".
Thanks!
Best regards, Andrey Borodin.
v8-0001-Prototype-B-tree-vacuum-streamlineing.patch
D
Hi!
On Fri, 25 Oct 2024 at 17:01, Andrey M. Borodin wrote:
>
>
>
> > On 25 Oct 2024, at 00:55, Rahila Syed wrote:
> >
> > While writing this email, I realized I evicted buffers for the table
> > and not the index. I will perform the test again. However,
> > I would like to know your opinion on w
> On 25 Oct 2024, at 00:55, Rahila Syed wrote:
>
> While writing this email, I realized I evicted buffers for the table
> and not the index. I will perform the test again. However,
> I would like to know your opinion on whether this looks like
> a valid test.
Well, yes, kind of, you need drop
> On 24 Oct 2024, at 10:15, Andrey M. Borodin wrote:
>
> I've also added GiST vacuum to the patchset.
I decided to add up a SP-GiST while having launched on pgconf.eu.
Best regards, Andrey Borodin.
v7-0001-Prototype-B-tree-vacuum-streamlineing.patch
Description: Binary data
v7-0002-Use-r
Hi Andrey,
I ran the following test with
v7-0001-Prototype-B-tree-vacuum-streamlineing.patch
to measure the performance improvement.
--Table size of approx 2GB (Fits in RAM)
postgres=# create unlogged table x_big as select i from
generate_series(1,6e7) i;
SELECT 6000
postgres=# create index o
I've also added GiST vacuum to the patchset.
> On 24 Oct 2024, at 01:04, Melanie Plageman wrote:
>
> On Wed, Oct 23, 2024 at 4:29 PM Andrey M. Borodin
> wrote:
>>
>>> On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
>>>
>>> I'll think how to restructure flow there...
>>
>> OK, I've under
On Wed, Oct 23, 2024 at 4:29 PM Andrey M. Borodin wrote:
>
> > On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
> >
> > I'll think how to restructure flow there...
>
> OK, I've understood how it should be structured. PFA v5. Sorry for the noise.
I think this would be a bit nicer:
while (Buffe
> On 23 Oct 2024, at 20:57, Andrey M. Borodin wrote:
>
> I'll think how to restructure flow there...
OK, I've understood how it should be structured. PFA v5. Sorry for the noise.
Best regards, Andrey Borodin.
v5-0001-Prototype-B-tree-vacuum-streamlineing.patch
Description: Binary data
Thanks!
> On 23 Oct 2024, at 18:17, Melanie Plageman wrote:
>
>
> Note that you don't check if buf is valid here and break out of the
> inner loop when it is invalid.
I've added two asserts to clarify expectations.
>
> By doing read_stream_reset() before you first invoke
> read_stream_next_b
On Wed, Oct 23, 2024 at 9:32 AM Andrey M. Borodin wrote:
>
> > On 22 Oct 2024, at 16:42, Melanie Plageman
> > wrote:
> >
> > Ah, right, the callback might return InvalidBlockNumber far before
> > we've actually read (and vacuumed) the blocks it is specifying.
>
> I've discussed the issue with Th
On Wed, Oct 23, 2024 at 9:32 PM Andrey M. Borodin wrote:
>
>
>
> > On 22 Oct 2024, at 16:42, Melanie Plageman
> > wrote:
> >
> > Ah, right, the callback might return InvalidBlockNumber far before
> > we've actually read (and vacuumed) the blocks it is specifying.
>
> I've discussed the issue wit
> On 22 Oct 2024, at 16:42, Melanie Plageman wrote:
>
> Ah, right, the callback might return InvalidBlockNumber far before
> we've actually read (and vacuumed) the blocks it is specifying.
I've discussed the issue with Thomas on PGConf.eu and he proposed to use stream
reset.
PFA v3.
Best re
On Tue, Oct 22, 2024 at 2:30 AM Andrey M. Borodin wrote:
>
> > On 22 Oct 2024, at 00:05, Melanie Plageman
> > wrote:
> >
> > I was suggesting you call RelationGetNumberOfBlocks() once
> > current_block == last_exclusive in the callback itself.
>
> Consider following sequence of events:
>
> 0. We
> On 22 Oct 2024, at 00:05, Melanie Plageman wrote:
>
> I was suggesting you call RelationGetNumberOfBlocks() once
> current_block == last_exclusive in the callback itself.
Consider following sequence of events:
0. We schedule some buffers for IO
1. We call RelationGetNumberOfBlocks() in cal
On Mon, Oct 21, 2024 at 4:49 PM Andrei Borodin wrote:
>
> 21.10.2024, 22:34, "Melanie Plageman" :
>
> The whole point of the read stream callback provided by the caller is
> that the logic to get the next block should be there
>
> We must get number of blocks after examining last block. But callba
Melanie, thanks for your comments.21.10.2024, 22:34, "Melanie Plageman" :The whole point of the read stream callback provided by the caller isthat the logic to get the next block should be thereWe must get number of blocks after examining last block. But callback returning EOF might be called befor
On Mon, Oct 21, 2024 at 3:34 PM Melanie Plageman
wrote:
>
> For the outer loop, I feel like we have options. For example, maybe
> the read stream callback can call RelationGetNumberOfBlocks(). I mean
> maybe we don't want to have to take a relation extension lock in a
> callback.
Also, given thi
On Sun, Oct 20, 2024 at 10:19 AM Andrey M. Borodin wrote:
>
>
>
> > On 20 Oct 2024, at 15:16, Junwang Zhao wrote:
> >
> > I'm not sure if I did not express myself correctly, I didn't mean to
> > restart the stream,
> > I mean we can create a new stream for each outer loop, I attached a
> > refact
> On 20 Oct 2024, at 15:16, Junwang Zhao wrote:
>
> I'm not sure if I did not express myself correctly, I didn't mean to
> restart the stream,
> I mean we can create a new stream for each outer loop, I attached a
> refactor 0002
> based on your 0001, correct me if I'm wrong.
I really like how
On Sun, Oct 20, 2024 at 3:19 PM Andrey M. Borodin wrote:
>
>
>
> > On 19 Oct 2024, at 20:41, Junwang Zhao wrote:
> >
> > I'm wondering why is the case, ISTM that we can do *p.current_blocknum
> > = scanblkno*
> > and *p.last_exclusive = num_pages* in each loop of the outer for?
>
> Thanks for rev
> On 19 Oct 2024, at 20:41, Junwang Zhao wrote:
>
> I'm wondering why is the case, ISTM that we can do *p.current_blocknum
> = scanblkno*
> and *p.last_exclusive = num_pages* in each loop of the outer for?
Thanks for reviewing!
AFAIK we cannot restart stream if it's finished, so we have a rac
Hi Andrey,
On Sat, Oct 19, 2024 at 5:39 PM Andrey M. Borodin wrote:
>
> Hi hackers!
>
> On a recent hacking workshop [0] Thomas mentioned that patches using new API
> would be welcomed.
> So I prototyped streamlining of B-tree vacuum for a discussion.
> When cleaning an index we must visit every
Hi hackers!
On a recent hacking workshop [0] Thomas mentioned that patches using new API
would be welcomed.
So I prototyped streamlining of B-tree vacuum for a discussion.
When cleaning an index we must visit every index tuple, thus we uphold a
special invariant:
After checking a trailing block,
24 matches
Mail list logo
