On Fri, Aug 9, 2024 at 11:48 AM Melanie Plageman
wrote:
> In the adaptive freezing code, I use the time stream to answer a yes
> or no question. I translate a time in the past (now -
> target_freeze_duration) to an LSN so that I can determine if a page
> that is being modified for the first time a
On Fri, Aug 9, 2024 at 1:03 PM Tomas Vondra wrote:
>
> On 8/9/24 17:48, Melanie Plageman wrote:
> > On Fri, Aug 9, 2024 at 9:15 AM Melanie Plageman
> > wrote:
> >>
> >> On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
> >>>
> >>> I suggest we do the simplest and most obvious algorithm possible
On 8/9/24 15:09, Melanie Plageman wrote:
>
> ...
>
> Okay, so as I think about evaluating a few new algorithms, I realize
> that we do need some sort of criteria. I started listing out what I
> feel is "reasonable" accuracy and plotting it to see if the
> relationship is linear/exponential/etc. I
On 8/9/24 17:48, Melanie Plageman wrote:
> On Fri, Aug 9, 2024 at 9:15 AM Melanie Plageman
> wrote:
>>
>> On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
>>>
>>> I suggest we do the simplest and most obvious algorithm possible, at
>>> least for now. Focusing on this part seems like a distracti
On Fri, Aug 9, 2024 at 9:15 AM Melanie Plageman
wrote:
>
> On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
> >
> > I suggest we do the simplest and most obvious algorithm possible, at
> > least for now. Focusing on this part seems like a distraction from the
> > freezing thing you actually wan
On Fri, Aug 9, 2024 at 9:09 AM Tomas Vondra wrote:
>
>
>
> On 8/9/24 03:02, Melanie Plageman wrote:
> > On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> >> each seconds. And we want to allow merging stuff nicely. The smallest
> >> merges we could do is 1s -> 2s -> 4s -> 8s -> ... but let's sa
On Thu, Aug 8, 2024 at 9:02 PM Melanie Plageman
wrote:
>
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> >
> > Maybe it'd be good to approach this from the opposite direction, say
> > what "accuracy guarantees" we want to provide, and then design the
> > structure / algorithm to ensure tha
On 8/9/24 03:02, Melanie Plageman wrote:
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
>>
>> On 8/7/24 21:39, Melanie Plageman wrote:
>>> On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
As I mentioned to you off-list, I feel like this needs some sort of
recency bias. Ce
On 8/9/24 03:29, Melanie Plageman wrote:
> On Thu, Aug 8, 2024 at 3:00 PM Robert Haas wrote:
>>
>> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
>>> A-D is already enough to cover 30h, with A-E it'd be ~300h. Do we need
>>> (or want) to keep a longer history?
>>
>> I think there is a differe
On Thu, Aug 8, 2024 at 3:00 PM Robert Haas wrote:
>
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> > A-D is already enough to cover 30h, with A-E it'd be ~300h. Do we need
> > (or want) to keep a longer history?
>
> I think there is a difference of opinion about this between Melanie
> and
On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
>
> On 8/7/24 21:39, Melanie Plageman wrote:
> > On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
> >>
> >> As I mentioned to you off-list, I feel like this needs some sort of
> >> recency bias. Certainly vacuum, and really almost any conceivabl
On Thu, Aug 8, 2024 at 8:39 PM Tomas Vondra wrote:
> Is there a reason not to make this just another SLRU, just like we do
> for commit_ts? I'm not saying it's perfect, but it's an approach we
> already use to solve these issues.
An SLRU is essentially an infinitely large array that grows at one
On 8/8/24 20:59, Robert Haas wrote:
> On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
>> How could we do this? We have 1s precision, so we start with buckets for
>> each seconds. And we want to allow merging stuff nicely. The smallest
>> merges we could do is 1s -> 2s -> 4s -> 8s -> ... but let
On Thu, Aug 8, 2024 at 2:34 PM Tomas Vondra wrote:
> How could we do this? We have 1s precision, so we start with buckets for
> each seconds. And we want to allow merging stuff nicely. The smallest
> merges we could do is 1s -> 2s -> 4s -> 8s -> ... but let's say we do
> 1s -> 10s -> 100s -> 1000s
On 8/7/24 21:39, Melanie Plageman wrote:
> On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
>>
>> As I mentioned to you off-list, I feel like this needs some sort of
>> recency bias. Certainly vacuum, and really almost any conceivable user
>> of this facility, is going to care more about accurate
On Wed, Aug 7, 2024 at 1:06 PM Robert Haas wrote:
>
> As I mentioned to you off-list, I feel like this needs some sort of
> recency bias. Certainly vacuum, and really almost any conceivable user
> of this facility, is going to care more about accurate answers for new
> data than for old data. If t
Melanie,
As I mentioned to you off-list, I feel like this needs some sort of
recency bias. Certainly vacuum, and really almost any conceivable user
of this facility, is going to care more about accurate answers for new
data than for old data. If there's no recency bias, then I think that
eventuall
Attached v7 changes the SQL-callable functions to return ranges of
LSNs and times covering the target time or LSN instead of linearly
interpolating an approximate answer.
I also changed the frequency and conditions under which the background
writer updates the global LSNTimeStream. There is now a
This is a copy of my message for pgsql-hackers mailing list. Unfortunately
original message was rejected due to one of recipients addresses is blocked.
> On 1 Aug 2024, at 10:54, Andrey M. Borodin wrote:
>
>
>
>> On 1 Aug 2024, at 05:44, Melanie Plageman wrote:
>>
>> Thanks for the review!
Thanks for the review! v6 attached.
On Sat, Jul 6, 2024 at 1:36 PM Andrey M. Borodin wrote:
>
> PgStartLSN = GetXLogInsertRecPtr();
> Should this be kind of RecoveryEndPtr? How is it expected to behave on
> Standby in HA cluster, which was doing a crash recovery of 1y WALs in a day,
> then is i
Hi!
I’m doing another iteration over the patchset.
PgStartLSN = GetXLogInsertRecPtr();
Should this be kind of RecoveryEndPtr? How is it expected to behave on Standby
in HA cluster, which was doing a crash recovery of 1y WALs in a day, then is in
startup for a year as a Hot Standby, and then is
On Wed, Jun 26, 2024 at 10:04 PM Melanie Plageman
wrote:
>
> I've implemented these review points in the attached v4.
I realized the docs had a compilation error. Attached v5 fixes that as
well as three bugs I found while using this patch set more intensely
today.
I see Michael has been working
Thanks so much Bharath, Andrey, and Ilya for the review!
I've posted a new version here [1] which addresses some of your
concerns. I'll comment on those it does not address inline.
On Thu, May 30, 2024 at 1:26 PM Andrey M. Borodin wrote:
>
> === Questions ===
> 1. The patch does not handle serve
Thanks for the review!
Attached v4 implements the new algorithm/compression described in [1].
We had discussed off-list possibly using error in some way. So, I'm
interested to know what you think about this method I suggested which
calculates error. It doesn't save the error so that we could use
On Mon, Mar 18, 2024 at 1:29 PM Tomas Vondra
wrote:
>
> On 2/22/24 03:45, Melanie Plageman wrote:
> > The attached v3 has a new algorithm. Now, LSNTimes are added from the
> > end of the array forward until all array elements have at least one
> > logical member (array length == volume). Once arra
Hi everyone!
Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we
got everything wrong, please consider that we are just doing training on
reviewing patches.
=== Purpose of the patch ===
Currently, we have checkpoint_timeout and max_wal size to know when we need a
c
On 3/18/24 15:02, Daniel Gustafsson wrote:
>> On 22 Feb 2024, at 03:45, Melanie Plageman wrote:
>> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
>> wrote:
>
>>> - Not sure why we need 0001. Just so that the "estimate" functions in
>>> 0002 have a convenient "start" point? Surely we could look a
On 2/22/24 03:45, Melanie Plageman wrote:
> Thanks so much for reviewing!
>
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> wrote:
>>
>> When I first read this, I immediately started wondering if this might
>> use the commit timestamp stuff we already have. Because for each commit
>> we alrea
> On 22 Feb 2024, at 03:45, Melanie Plageman wrote:
> On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
> wrote:
>> - Not sure why we need 0001. Just so that the "estimate" functions in
>> 0002 have a convenient "start" point? Surely we could look at the
>> current LSNTimeline data and use the oldest
Thanks so much for reviewing!
On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra
wrote:
>
> When I first read this, I immediately started wondering if this might
> use the commit timestamp stuff we already have. Because for each commit
> we already store the LSN and commit timestamp, right? But I'm not
Hi,
I took a look at this today, to try to understand the purpose and how it
works. Let me share some initial thoughts and questions I have. Some of
this may be wrong/missing the point, so apologies for that.
The goal seems worthwhile in general - the way I understand it, the
patch aims to provid
On Wed, Dec 27, 2023 at 5:16 PM Melanie Plageman
wrote:
>
> Elsewhere [1] I required a way to estimate the time corresponding to a
> particular LSN in the past. I devised the attached LSNTimeline, a data
> structure mapping LSNs <-> timestamps with decreasing precision for
> older time, LSN pairs.
Hi,
Elsewhere [1] I required a way to estimate the time corresponding to a
particular LSN in the past. I devised the attached LSNTimeline, a data
structure mapping LSNs <-> timestamps with decreasing precision for
older time, LSN pairs. This can be used to locate and translate a
particular time to
33 matches
Mail list logo
