On Mon, Jul 16, 2018 at 02:33:17PM -0400, Andrew Dunstan wrote:
> Ah, ok. Thanks. ignore the email I just sent about that.
So... This thread has basically died of inactivity, while there have
been a couple of interesting things discussed, like the version from
Heikki here:
https://www.postgresql.
On Fri, Apr 6, 2018 at 4:25 PM, Claudio Freire wrote:
>> True all that. My point is that the multi-segmented array isn't all that
>> simple and proven, compared to an also straightforward B-tree. It's pretty
>> similar to a B-tree, actually, except that it has exactly two levels, and
>> the node (
On 07/16/2018 11:35 AM, Claudio Freire wrote:
On Mon, Jul 16, 2018 at 11:34 AM Claudio Freire wrote:
On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
wrote:
On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
On 13/07/18 01:39, Andrew Dunstan wrote:
On 07/12/2018 06:34 PM, Alvaro Herrera w
On Mon, Jul 16, 2018 at 3:30 PM Andrew Dunstan
wrote:
>
>
>
> On 07/16/2018 10:34 AM, Claudio Freire wrote:
> > On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
> > wrote:
> >>
> >>
> >> On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
> >>> On 13/07/18 01:39, Andrew Dunstan wrote:
> On 07/12
On 07/16/2018 10:34 AM, Claudio Freire wrote:
On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
wrote:
On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
On 13/07/18 01:39, Andrew Dunstan wrote:
On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
On 2018-Jul-12, Andrew Dunstan wrote:
I fully un
On 16/07/18 18:35, Claudio Freire wrote:
On Mon, Jul 16, 2018 at 11:34 AM Claudio Freire wrote:
On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
wrote:
On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
Claudio raised a good point, that doing small pallocs leads to
fragmentation, and in particu
On Mon, Jul 16, 2018 at 11:34 AM Claudio Freire wrote:
>
> On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
> wrote:
> >
> >
> >
> > On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
> > > On 13/07/18 01:39, Andrew Dunstan wrote:
> > >> On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
> > >>> On 2018-
On Fri, Jul 13, 2018 at 5:43 PM Andrew Dunstan
wrote:
>
>
>
> On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
> > On 13/07/18 01:39, Andrew Dunstan wrote:
> >> On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
> >>> On 2018-Jul-12, Andrew Dunstan wrote:
> >>>
> I fully understand. I think this
On 07/13/2018 09:44 AM, Heikki Linnakangas wrote:
On 13/07/18 01:39, Andrew Dunstan wrote:
On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
On 2018-Jul-12, Andrew Dunstan wrote:
I fully understand. I think this needs to go back to "Waiting on
Author".
Why? Heikki's patch applies fine and pa
On 13/07/18 01:39, Andrew Dunstan wrote:
On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
On 2018-Jul-12, Andrew Dunstan wrote:
I fully understand. I think this needs to go back to "Waiting on Author".
Why? Heikki's patch applies fine and passes the regression tests.
Well, I understood Claudi
On 07/12/2018 06:34 PM, Alvaro Herrera wrote:
On 2018-Jul-12, Andrew Dunstan wrote:
I fully understand. I think this needs to go back to "Waiting on Author".
Why? Heikki's patch applies fine and passes the regression tests.
Well, I understood Claudio was going to do some more work (see
On 2018-Jul-12, Andrew Dunstan wrote:
> I fully understand. I think this needs to go back to "Waiting on Author".
Why? Heikki's patch applies fine and passes the regression tests.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Tr
On 07/12/2018 12:38 PM, Claudio Freire wrote:
On Thu, Jul 12, 2018 at 10:44 AM Andrew Dunstan
wrote:
On 04/06/2018 08:00 PM, Claudio Freire wrote:
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire wrote:
On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas wrote:
On 06/04/18 01:59, Claudi
On Thu, Jul 12, 2018 at 10:44 AM Andrew Dunstan
wrote:
>
>
>
> On 04/06/2018 08:00 PM, Claudio Freire wrote:
> > On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire
> > wrote:
> >> On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas
> >> wrote:
> >>> On 06/04/18 01:59, Claudio Freire wrote:
>
On 04/06/2018 08:00 PM, Claudio Freire wrote:
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire wrote:
On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas wrote:
On 06/04/18 01:59, Claudio Freire wrote:
The iteration interface, however, seems quite specific for the use
case of vacuumlazy, so
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire wrote:
> On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas wrote:
>> On 06/04/18 01:59, Claudio Freire wrote:
>>>
>>> The iteration interface, however, seems quite specific for the use
>>> case of vacuumlazy, so it's not really a good abstraction.
Claudio Freire wrote:
> On Fri, Apr 6, 2018 at 11:00 AM, Alvaro Herrera
> wrote:
> > FWIW I liked the idea of having this abstraction possibly do other
> > things -- for instance to vacuum brin indexes you'd like to mark index
> > tuples as "containing tuples that were removed" and eventually
>
Heikki Linnakangas wrote:
> On 06/04/18 01:59, Claudio Freire wrote:
> > The iteration interface, however, seems quite specific for the use
> > case of vacuumlazy, so it's not really a good abstraction.
>
> Can you elaborate? It does return the items one block at a time. Is that
> what you mean by
On 06/04/18 16:39, Heikki Linnakangas wrote:
Sure. I used the attached script to test this.
Sorry, I attached the wrong script. Here is the correct one that I used.
Here are also the results I got from running it
- Heikki
vacuumbenchone.sh
Description: application/shellscript
vacuumbench
On 06/04/18 01:59, Claudio Freire wrote:
The iteration interface, however, seems quite specific for the use
case of vacuumlazy, so it's not really a good abstraction.
Can you elaborate? It does return the items one block at a time. Is that
what you mean by being specific for vacuumlazy? I gues
On Thu, Apr 5, 2018 at 5:02 PM, Heikki Linnakangas wrote:
> On 03/04/18 17:20, Claudio Freire wrote:
>>
>> Ok, rebased patches attached
>
>
> Thanks! I took a look at this.
>
> First, now that the data structure is more complicated, I think it's time to
> abstract it, and move it out of vacuumlazy
On 03/04/18 17:20, Claudio Freire wrote:
Ok, rebased patches attached
Thanks! I took a look at this.
First, now that the data structure is more complicated, I think it's
time to abstract it, and move it out of vacuumlazy.c. The Tid Map needs
to support the following operations:
* Add TIDs,
On Tue, Apr 3, 2018 at 11:09 AM, Claudio Freire wrote:
> On Tue, Apr 3, 2018 at 11:06 AM, Claudio Freire
> wrote:
>> I didn't receive your comment, I just saw it. Nevertheless, I rebased the
>> patches a while ago just because I noticed they didn't apply anymore in
>> cputube, and they still s
On Tue, Apr 3, 2018 at 11:06 AM, Claudio Freire wrote:
> I didn't receive your comment, I just saw it. Nevertheless, I rebased the
> patches a while ago just because I noticed they didn't apply anymore in
> cputube, and they still seem to apply.
Sorry, that is false.
They appear green in cputu
I didn't receive your comment, I just saw it. Nevertheless, I rebased the
patches a while ago just because I noticed they didn't apply anymore in
cputube, and they still seem to apply.
Patch number 2 was committed a long while ago, that's why it's missing. It was
a simple patch, it landed rewri
Hello everyone,
I would like to let you know that unfortunately these patches don't apply
anymore. Also personally I'm a bit confused by the last message that has 0001-
and 0003- patches attached but not the 0002- one.
On Fri, Feb 9, 2018 at 1:05 PM, Claudio Freire wrote:
> Turns out that it was a tad oversized. 300k tuples seems enough.
>
> Attached is a new patch version that:
>
> - Uses an unlogged table to make the large mwm test faster
> - Uses a wait_barrier helper that waits for concurrent transactions
>
On Fri, Aug 18, 2017 at 8:39 AM, Claudio Freire wrote:
> On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire
> wrote:
>> Indeed they do, and that's what motivated this patch. But I'd need
>> TB-sized tables to set up something like that. I don't have the
>> hardware or time available to do that (vac
On Fri, Feb 9, 2018 at 10:32 AM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>> On Thu, Feb 8, 2018 at 8:39 PM, Alvaro Herrera
>> wrote:
>
>> During the process of developing the patch, I got seriously broken
>> code that passed the tests nonetheless. The test as it was was very
>> ineffective
Claudio Freire wrote:
> On Thu, Feb 8, 2018 at 8:39 PM, Alvaro Herrera
> wrote:
> During the process of developing the patch, I got seriously broken
> code that passed the tests nonetheless. The test as it was was very
> ineffective at actually detecting issues.
>
> This new test may be slow, b
On Thu, Feb 8, 2018 at 8:39 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>
>> I don't like looping, though, seems overly cumbersome. What's worse?
>> maintaining that fragile weird loop that might break (by causing
>> unexpected output), or a slight slowdown of the test suite?
>>
>> I don't k
Claudio Freire wrote:
> I don't like looping, though, seems overly cumbersome. What's worse?
> maintaining that fragile weird loop that might break (by causing
> unexpected output), or a slight slowdown of the test suite?
>
> I don't know how long it might take on slow machines, but in my
> machin
On Thu, Feb 8, 2018 at 2:44 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I looked this a bit closer.
>
> In upthread[1] Robert mentioned the exponentially increasing size
> of additional segments.
>
>>> Hmm, I had imagined making all of the segments the same size rather
>>> than having the size grow expo
Hello, I looked this a bit closer.
In upthread[1] Robert mentioned the exponentially increasing size
of additional segments.
>> Hmm, I had imagined making all of the segments the same size rather
>> than having the size grow exponentially. The whole point of this is
>> to save memory, and even i
On Thu, Feb 8, 2018 at 12:13 AM, Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera
> wrote:
>> Claudio Freire wrote:
>>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
>>> wrote:
>>> >> Waiting as you say would be akin to what the patch does by putting
>>> >> vacuum on it
On Wed, Feb 7, 2018 at 11:29 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
>> wrote:
>> >> Waiting as you say would be akin to what the patch does by putting
>> >> vacuum on its own parallel group.
>> >
>> > I don't think it's the same. We d
Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera
> wrote:
> >> Waiting as you say would be akin to what the patch does by putting
> >> vacuum on its own parallel group.
> >
> > I don't think it's the same. We don't need to wait until all the
> > concurrent tests are done --
On Wed, Feb 7, 2018 at 8:52 PM, Alvaro Herrera wrote:
>> Waiting as you say would be akin to what the patch does by putting
>> vacuum on its own parallel group.
>
> I don't think it's the same. We don't need to wait until all the
> concurrent tests are done -- we only need to wait until the trans
Claudio Freire wrote:
> On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera
> wrote:
> > Claudio Freire wrote:
> > Hmm, this solution is not very friendly to the goal of reducing test
> > runtime, particularly since the new test creates a nontrivial-sized
> > table. Maybe we can find a better altern
On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera wrote:
> Claudio Freire wrote:
>
>> - vacuum test on its own parallel group
>
> Hmm, this solution is not very friendly to the goal of reducing test
> runtime, particularly since the new test creates a nontrivial-sized
> table. Maybe we can find a be
Claudio Freire wrote:
> - vacuum test on its own parallel group
Hmm, this solution is not very friendly to the goal of reducing test
runtime, particularly since the new test creates a nontrivial-sized
table. Maybe we can find a better alternative. Can we use some wait
logic instead? Maybe some
On Wed, Feb 7, 2018 at 12:50 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire
> wrote in
>> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire
>> wrote:
>> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
>> > wrote:
>> >>> It's starting to look lik
Hello,
At Tue, 6 Feb 2018 10:41:22 -0300, Claudio Freire
wrote in
> On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire
> wrote:
> > On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
> > wrote:
> >>> It's starting to look like a timing effect indeed.
> >>
> >> It seems to be truncation skip, may
On Tue, Feb 6, 2018 at 10:18 AM, Claudio Freire wrote:
> On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
> wrote:
>>> It's starting to look like a timing effect indeed.
>>
>> It seems to be truncation skip, maybe caused by concurrent
>> autovacuum.
>
> Good point, I'll also disable autovacuum o
On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
wrote:
>> It's starting to look like a timing effect indeed.
>
> It seems to be truncation skip, maybe caused by concurrent
> autovacuum.
Good point, I'll also disable autovacuum on vactst.
> See lazy_truncate_heap() for details. Updates of
> pg_
Hello,
At Fri, 2 Feb 2018 19:52:02 -0300, Claudio Freire
wrote in
> On Thu, Jan 25, 2018 at 6:21 PM, Thomas Munro
> wrote:
> > On Fri, Jan 26, 2018 at 9:38 AM, Claudio Freire
> > wrote:
> >> I had the tests running in a loop all day long, and I cannot reproduce
> >> that variance.
> >>
> >>
On Thu, Jan 25, 2018 at 6:21 PM, Thomas Munro
wrote:
> On Fri, Jan 26, 2018 at 9:38 AM, Claudio Freire
> wrote:
>> I had the tests running in a loop all day long, and I cannot reproduce
>> that variance.
>>
>> Can you share your steps to reproduce it, including configure flags?
>
> Here are two
On Fri, Jan 26, 2018 at 9:38 AM, Claudio Freire wrote:
> I had the tests running in a loop all day long, and I cannot reproduce
> that variance.
>
> Can you share your steps to reproduce it, including configure flags?
Here are two build logs where it failed:
https://travis-ci.org/postgresql-cfbo
On Thu, Jan 25, 2018 at 10:56 AM, Claudio Freire wrote:
> On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro
> wrote:
>> On Thu, Jan 18, 2018 at 9:17 AM, Claudio Freire
>> wrote:
>>> Huh. That was simpler than I thought.
>>>
>>> Attached rebased versions.
>>
>> Hi Claudio,
>>
>> FYI the regression t
Claudio Freire wrote:
> On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro
> wrote:
> > *** 128,134
> > SELECT pg_relation_size('vactst', 'main');
> >pg_relation_size
> > --
> > ! 0
> > (1 row)
> >
> > SELECT count(*) FROM vactst;
> > --- 128,134
>
On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro
wrote:
> On Thu, Jan 18, 2018 at 9:17 AM, Claudio Freire
> wrote:
>> Huh. That was simpler than I thought.
>>
>> Attached rebased versions.
>
> Hi Claudio,
>
> FYI the regression test seems to have some run-to-run variation.
> Though it usually succe
On Thu, Jan 18, 2018 at 9:17 AM, Claudio Freire wrote:
> Huh. That was simpler than I thought.
>
> Attached rebased versions.
Hi Claudio,
FYI the regression test seems to have some run-to-run variation.
Though it usually succeeds, recently I have seen a couple of failures
like this:
= C
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I can confirm that these patches don't break anything; the co
On Wed, Jan 17, 2018 at 5:02 PM, Claudio Freire
wrote:
>
>
> On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote:
>
>> Greetings,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire
>> wrote:
>> > > They did apply at the time, but I thi
On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire
> wrote:
> > > They did apply at the time, but I think major work on vacuum was
> > > pushed since then, and also I was tr
Greetings,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire wrote:
> > They did apply at the time, but I think major work on vacuum was
> > pushed since then, and also I was traveling so out of reach.
> >
> > It may take some time to rebase the
On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire wrote:
> They did apply at the time, but I think major work on vacuum was
> pushed since then, and also I was traveling so out of reach.
>
> It may take some time to rebase them again. Should I move to needs
> review myself after that?
Sure, if you c
On Tue, Nov 28, 2017 at 10:37 PM, Michael Paquier
wrote:
> On Mon, Oct 2, 2017 at 11:02 PM, Claudio Freire
> wrote:
>> Rebased version of the patches attached
>
> The status of the patch is misleading:
> https://commitfest.postgresql.org/15/844/. This was marked as waiting
> on author but a new
On Mon, Oct 2, 2017 at 11:02 PM, Claudio Freire wrote:
> Rebased version of the patches attached
The status of the patch is misleading:
https://commitfest.postgresql.org/15/844/. This was marked as waiting
on author but a new version has been published. Let's be careful.
The last patches I am aw
59 matches
Mail list logo
