Hi,
On Tue, Jan 07, 2025 at 10:19:36PM +0100, Tomas Vondra wrote:
> On 1/7/25 21:42, Robert Treat wrote:
> > On Tue, Jan 7, 2025 at 10:44 AM Bertrand Drouvot
> > wrote:
> >>
> >> ...
> >>
> >> Another idea regarding the storage of those metrics: I think that one would
> >> want to see "precise" d
On 1/7/25 21:42, Robert Treat wrote:
> On Tue, Jan 7, 2025 at 10:44 AM Bertrand Drouvot
> wrote:
>>
>> ...
>>
>> Another idea regarding the storage of those metrics: I think that one would
>> want to see "precise" data for recent metrics but would probably be fine
>> with some
>> level of aggrega
On Tue, Jan 7, 2025 at 10:44 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Dec 25, 2024 at 06:25:50PM +0100, Tomas Vondra wrote:
> > Hi,
> >
> > On 12/23/24 07:35, wenhui qiu wrote:
> > > Hi Tomas
> > > This is a great feature.
> > > + /*
> > > + * Define (or redefine) custom GUC variables.
Hi,
On Wed, Dec 25, 2024 at 06:25:50PM +0100, Tomas Vondra wrote:
> Hi,
>
> On 12/23/24 07:35, wenhui qiu wrote:
> > Hi Tomas
> > This is a great feature.
> > + /*
> > + * Define (or redefine) custom GUC variables.
> > + */
> > + DefineCustomIntVariable("stats_history.size",
> > + "Sets t
On 31/12/2024 16:06, Tomas Vondra wrote:
On 12/31/24 02:06, Michael Paquier wrote:
On Sat, Dec 28, 2024 at 02:25:16AM +0100, Tomas Vondra wrote:
And the more I think about it the more I'm convinced we don't need to
keep the data about past runs in memory, a file should be enough (except
maybe
On Dec 31, 2024, at 9:20 AM, Tomas Vondra wrote:
>
>> Speaking of retention, it would be nice if this feature allowed users to
>> DELETE from the view that presented the data. That would allow for any
>> kind of custom config that someone could dream up.
>
> I really don't intend / want to do th
On 12/30/24 22:40, Jim Nasby wrote:
> On Dec 25, 2024, at 11:25 AM, Tomas Vondra wrote:
>> But maybe it'd be possible to just write the entries to a file. We don't
>> need random access to past entries (unlike e.g. pg_stat_statements), and
>> people won't query that very often either.
>
> Assumin
On 12/31/24 02:06, Michael Paquier wrote:
> On Sat, Dec 28, 2024 at 02:25:16AM +0100, Tomas Vondra wrote:
>> And the more I think about it the more I'm convinced we don't need to
>> keep the data about past runs in memory, a file should be enough (except
>> maybe for a small buffer). That would mea
On Sat, Dec 28, 2024 at 02:25:16AM +0100, Tomas Vondra wrote:
> And the more I think about it the more I'm convinced we don't need to
> keep the data about past runs in memory, a file should be enough (except
> maybe for a small buffer). That would mean we don't need to worry about
> dynamic shared
On Dec 25, 2024, at 11:25 AM, Tomas Vondra wrote:
> But maybe it'd be possible to just write the entries to a file. We don't
> need random access to past entries (unlike e.g. pg_stat_statements), and
> people won't query that very often either.
Assuming this doesn’t add significant complexity I t
On 12/29/24 16:39, Robert Treat wrote:
> On Fri, Dec 27, 2024 at 8:25 PM Tomas Vondra wrote:
>> On 12/27/24 05:00, Michael Paquier wrote:
>>> On Thu, Dec 26, 2024 at 06:58:11PM +0100, Tomas Vondra wrote:
If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
make a fund
On Fri, Dec 27, 2024 at 8:25 PM Tomas Vondra wrote:
> On 12/27/24 05:00, Michael Paquier wrote:
> > On Thu, Dec 26, 2024 at 06:58:11PM +0100, Tomas Vondra wrote:
> >> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> >> make a fundamental difference ...
> >>
> >> Anyway, t
On 12/27/24 05:00, Michael Paquier wrote:
> On Thu, Dec 26, 2024 at 06:58:11PM +0100, Tomas Vondra wrote:
>> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
>> make a fundamental difference ...
>>
>> Anyway, the 128MB value is rather arbitrary. I don't mind increasing th
On Thu, Dec 26, 2024 at 06:58:11PM +0100, Tomas Vondra wrote:
> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> make a fundamental difference ...
>
> Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
> limit, or possibly removing it entirely (and a
Hi Tomas
> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> make a fundamental difference ...
agree
> Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
> limit, or possibly removing it entirely (and accepting anything the
> system can handle).
yes,
On 12/26/24 17:00, wenhui qiu wrote:
> Hi
>
> As far as I know, more than 10,000 tables of instances are often
> encountered,
> So I insist that the maximum can be appropriately increased to 256MB，
> Can be more adaptable to many table situations
>
If 128MB is insufficient, why would 256MB
Hi
As far as I know, more than 10,000 tables of instances are often
encountered,
So I insist that the maximum can be appropriately increased to 256MB，Can be
more adaptable to many table situations
On Thu, 26 Dec 2024 at 23:23, Robert Treat wrote:
> On Wed, Dec 25, 2024 at 12:26 PM Tomas Vondr
On Wed, Dec 25, 2024 at 12:26 PM Tomas Vondra wrote:
>
> Hi,
>
> On 12/23/24 07:35, wenhui qiu wrote:
> > Hi Tomas
> > This is a great feature.
> > + /*
> > + * Define (or redefine) custom GUC variables.
> > + */
> > + DefineCustomIntVariable("stats_history.size",
> > + "Sets the amount of me
Hi,
On 12/23/24 07:35, wenhui qiu wrote:
> Hi Tomas
> This is a great feature.
> + /*
> + * Define (or redefine) custom GUC variables.
> + */
> + DefineCustomIntVariable("stats_history.size",
> + "Sets the amount of memory available for past events.",
> + NULL,
> + &statsHistorySizeMB,
> +
Hi Tomas
This is a great feature.
+ /*
+ * Define (or redefine) custom GUC variables.
+ */
+ DefineCustomIntVariable("stats_history.size",
+ "Sets the amount of memory available for past events.",
+ NULL,
+ &statsHistorySizeMB,
+ 1,
+ 1,
+ 128,
+ PGC_POSTMASTER,
+ GUC_UNIT_MB,
+ NULL,
+ NULL,
20 matches
Mail list logo
