On Thu, Nov 7, 2019 at 10:28 AM Bruce Momjian wrote:
> The above is a very good summary of the constraints that have led to our
> current handling of XID wraparound. If we are concerned about excessive
> vacuum freeze overhead, why is the default autovacuum_freeze_max_age =
> 2 so low? T
On Tue, Nov 5, 2019 at 09:34:52AM +1300, Thomas Munro wrote:
> On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra
> > Agreed. I think code complexity is part of the trade-off. IMO it's fine
> > to hack existing heap AM initially, and only explore the separate AM if
> > that turns out to be promising.
>
On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra
wrote:
> On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
> >On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
> >> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> >> > And "without causing significant issues elsewhere" unf
On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
Hi,
On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> And "without causing significant issues elsewhere" unfortunately
> includes continuing to allow pg_upgrade to wor
Hi,
On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> > And "without causing significant issues elsewhere" unfortunately
> > includes continuing to allow pg_upgrade to work.
> Yeah. I suppose we could have a different AM implement
On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
Hi,
(I've not read the rest of this thread yet)
On 2019-11-04 16:07:23 +0100, Tomas Vondra wrote:
On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
> And yet, if I try to implement a similar mechanism, if successful,
Hi,
(I've not read the rest of this thread yet)
On 2019-11-04 16:07:23 +0100, Tomas Vondra wrote:
> On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
> > And yet, if I try to implement a similar mechanism, if successful, will my
> > revision be considered?
> >
>
> Why wouldn'
On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
And yet, if I try to implement a similar mechanism, if successful, will my
revision be considered?
Why wouldn't it be considered? If you submit a patch that demonstrably
improves the behavior (in this case reduces per-tuple o
And yet, if I try to implement a similar mechanism, if successful, will my revision be considered? regards03.11.2019, 22:15, "Tomas Vondra" :On Sun, Nov 03, 2019 at 02:17:15PM +0300, Павел Ерёмин wrote: I completely agree with all of the above. Therefore, the proposed mechanism may entail large
On Sat, Nov 2, 2019 at 6:15 AM Tomas Vondra
wrote:
> On Fri, Nov 01, 2019 at 12:05:12PM +0300, Павел Ерёмин wrote:
> > Hi.
> > sorry for my English.
> > I want to once again open the topic of 64 bit transaction id. I did not
> > manage to find in the archive of the option that I want to di
On Sun, Nov 03, 2019 at 02:17:15PM +0300, Павел Ерёмин wrote:
I completely agree with all of the above. Therefore, the proposed
mechanism may entail larger improvements (and not only VACUUM).
I think the best think you can do is try implementing this ...
I'm afraid the "improvements" essen
I completely agree with all of the above. Therefore, the proposed mechanism may entail larger improvements (and not only VACUUM).I can offer the following solution.For VACUUM, create a hash table.VACUUM scanning the table sees that the version (tuple1) has t_ctid filled and refers to the address tu
On Sat, Nov 02, 2019 at 11:35:09PM +0300, Павел Ерёмин wrote:
The proposed option is not much different from what it is now.
We are not trying to save some space - we will reuse the existing one. We
just work in 64 bit transaction counters. Correct me if I'm wrong - the
address of the nex
The proposed option is not much different from what it is now.We are not trying to save some space - we will reuse the existing one. We just work in 64 bit transaction counters. Correct me if I'm wrong - the address of the next version of the line is stored in the 6 byte field t_cid in the tuple he
The proposed option does not need to change the length of either the page header or tuple header. Therefore, you will not need to physically change the data. regards01.11.2019, 20:10, "Tomas Vondra" :On Fri, Nov 01, 2019 at 10:25:17AM +0100, Pavel Stehule wrote:Hipá 1. 11. 2019 v 10:11 odesílatel
On Sat, Nov 02, 2019 at 07:07:17PM +0300, Павел Ерёмин wrote:
The proposed option does not need to change the length of either the page
header or tuple header. Therefore, you will not need to physically change
the data.
So how do you link the tuple versions together? Clearly, that
On Fri, Nov 01, 2019 at 12:05:12PM +0300, Павел Ерёмин wrote:
Hi.
sorry for my English.
I want to once again open the topic of 64 bit transaction id. I did not
manage to find in the archive of the option that I want to discuss, so I
write. If I searched poorly, then please forgive me.
On Fri, Nov 01, 2019 at 10:25:17AM +0100, Pavel Stehule wrote:
Hi
pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин
napsal:
Hi.
sorry for my English.
I want to once again open the topic of 64 bit transaction id. I did not
manage to find in the archive of the option that I want to discuss, so I
w
Hi
pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин
napsal:
> Hi.
> sorry for my English.
> I want to once again open the topic of 64 bit transaction id. I did not
> manage to find in the archive of the option that I want to discuss, so I
> write. If I searched poorly, then please forgive me.
> Th
19 matches
Mail list logo
