Hi,
On Tue, Dec 03, 2024 at 10:31:15AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote:
> > On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
> > wrote:
> > > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> > > > If we don’t ha
Hi,
On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote:
> On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
> wrote:
> > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> > > If we don’t have the relation OID when writing buffers out, can we
> > > just store oid to bufferta
On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
wrote:
> On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> > If we don’t have the relation OID when writing buffers out, can we
> > just store oid to buffertag mapping somewhere and use it?
>
> Do you mean add the relation OID into the
Hi,
On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> On Tue, 5 Nov 2024 at 11:06, Bertrand Drouvot
> wrote:
> >
> >
> > Does it sound ok to you to move with the above principal? (I'm +1 on it).
> >
>
> Hi! I looked through this thread.
Thanks for looking at it!
> Looks like we
On Tue, 5 Nov 2024 at 11:06, Bertrand Drouvot
wrote:
>
>
> Does it sound ok to you to move with the above principal? (I'm +1 on it).
>
Hi! I looked through this thread.
Looks like we are still awaiting a patch which stores more counters
(n_dead_tup, ... etc) into relfilenode stats. So, I assume t
On Tue, Nov 5, 2024 at 1:06 AM Bertrand Drouvot
wrote:
> Does it sound ok to you to move with the above principal? (I'm +1 on it).
Yes, provided we can get a clean implementation of it.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On Mon, Nov 04, 2024 at 02:51:10PM -0500, Robert Haas wrote:
> On Mon, Nov 4, 2024 at 4:27 AM Bertrand Drouvot
> wrote:
> > Then I think we should go with the "sometimes I don't know the relation OID
> > so I want to use the relfilenumber instead, without changing the user
> > experience"
>
On Mon, Nov 4, 2024 at 4:27 AM Bertrand Drouvot
wrote:
> Then I think we should go with the "sometimes I don't know the relation OID
> so I want to use the relfilenumber instead, without changing the user
> experience"
> way.
So does the latest version of the patch implement that principal
unifo
_and_contents(Oid dboid)
bool
pgstat_drop_entry(PgStat_Kind kind, Oid dboid, uint64 objid)
{
- PgStat_HashKey key = {.kind = kind,.dboid = dboid,.objid = objid};
+ PgStat_HashKey key;
PgStatShared_HashEntry *shent;
bool freed = true;
+ /* clear padding */
+ memset(&key, 0, sizeof(struct PgStat
Hi,
On Tue, Sep 10, 2024 at 05:30:32AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Sep 05, 2024 at 04:48:36AM +, Bertrand Drouvot wrote:
> > Please find attached a mandatory rebase.
> >
> > In passing, checking if based on the previous discussion (and given that we
> > don't have the re
p 17 00:00:00 2001
From: Bertrand Drouvot
Date: Thu, 16 Nov 2023 02:30:01 +
Subject: [PATCH v5] Provide relfilenode statistics
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We currently don’t have writes counters for relations.
The reason is that we
u see another approach
that the one this patch is implementing?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From 095af2878f8ab85509766807f60e0dadcf0cd018 Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date:
eed01478cdbe36673ef18247452e579f3b Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Thu, 16 Nov 2023 02:30:01 +
Subject: [PATCH v3] Provide relfilenode statistics
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We currently don’t have writes counte
Hi,
On Thu, Jul 11, 2024 at 01:58:19PM +0900, Michael Paquier wrote:
> On Wed, Jul 10, 2024 at 01:38:06PM +, Bertrand Drouvot wrote:
> > So, I think it makes sense to link the hashkey to all the RelFileLocator
> > fields, means:
> >
> > dboid (linked to RelFileLocator's dbOid)
> > objoid (lin
On Wed, Jul 10, 2024 at 01:38:06PM +, Bertrand Drouvot wrote:
> On Wed, Jul 10, 2024 at 03:02:34PM +0900, Michael Paquier wrote:
>> and I am troubled by the approach taken (mentioned down by you), but
>> that's invasive compared to how pgstats wants to be transparent with
>> its stats kinds.
>>
Hi,
On Wed, Jul 10, 2024 at 03:02:34PM +0900, Michael Paquier wrote:
> On Sat, May 25, 2024 at 07:52:02AM +, Bertrand Drouvot wrote:
> > But I think that it is in a state that can be used to discuss the approach
> > it
> > is implementing (so that we can agree or not on it) before moving
> >
On Sat, May 25, 2024 at 07:52:02AM +, Bertrand Drouvot wrote:
> But I think that it is in a state that can be used to discuss the approach it
> is implementing (so that we can agree or not on it) before moving
> forward.
I have read through the patch to get an idea of how things are done,
and
Hi,
On Tue, Jun 11, 2024 at 03:35:23PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 10 Jun 2024 08:09:56 +, Bertrand Drouvot
> wrote in
> >
> > My idea was to move all that is in pg_statio_all_tables to relfilenode stats
> > and 1) add new stats to pg_statio_all_tables (like heap_blks_written
At Mon, 10 Jun 2024 08:09:56 +, Bertrand Drouvot
wrote in
> Hi,
>
> On Fri, Jun 07, 2024 at 09:24:41AM -0400, Robert Haas wrote:
> > On Thu, Jun 6, 2024 at 11:17 PM Andres Freund wrote:
> > > If we just want to keep prior stats upon arelation rewrite, we can just
> > > copy
> > > the stat
Hi,
On Fri, Jun 07, 2024 at 09:24:41AM -0400, Robert Haas wrote:
> On Thu, Jun 6, 2024 at 11:17 PM Andres Freund wrote:
> > If we just want to keep prior stats upon arelation rewrite, we can just copy
> > the stats from the old relfilenode. Or we can decide that those stats don't
> > really make
On Thu, Jun 6, 2024 at 11:17 PM Andres Freund wrote:
> If we just want to keep prior stats upon arelation rewrite, we can just copy
> the stats from the old relfilenode. Or we can decide that those stats don't
> really make sense anymore, and start from scratch.
I think we need to think carefull
Hi,
On Thu, Jun 06, 2024 at 08:17:36PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-06-06 12:27:49 -0400, Robert Haas wrote:
> > On Wed, Jun 5, 2024 at 1:52 AM Bertrand Drouvot
> > wrote:
> > > I think we should keep the stats in the relation during relfilenode
> > > changes.
> > > As a POC, v
Hi,
On Thu, Jun 06, 2024 at 08:38:06PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-06-03 11:11:46 +, Bertrand Drouvot wrote:
> > The main argument is that we currently don’t have writes counters for
> > relations.
> > The reason is that we don’t have the relation OID when writing buffers o
Hi,
On 2024-06-03 11:11:46 +, Bertrand Drouvot wrote:
> The main argument is that we currently don’t have writes counters for
> relations.
> The reason is that we don’t have the relation OID when writing buffers out.
> Tracking writes per relfilenode would allow us to track/consolidate writes
Hi,
On 2024-06-06 12:27:49 -0400, Robert Haas wrote:
> On Wed, Jun 5, 2024 at 1:52 AM Bertrand Drouvot
> wrote:
> > I think we should keep the stats in the relation during relfilenode changes.
> > As a POC, v1 implemented a way to do so during TRUNCATE (see the changes in
> > table_relation_set_n
On Wed, Jun 5, 2024 at 1:52 AM Bertrand Drouvot
wrote:
> I think we should keep the stats in the relation during relfilenode changes.
> As a POC, v1 implemented a way to do so during TRUNCATE (see the changes in
> table_relation_set_new_filelocator() and in pg_statio_all_tables): as you can
> see
es: https://aws.amazon.com
>From 81d25e077c9f4eafa5304c257d1b39ee8a811628 Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Thu, 16 Nov 2023 02:30:01 +
Subject: [PATCH v2] Provide relfilenode statistics
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We cur
On Tue, Jun 04, 2024 at 09:26:27AM -0400, Robert Haas wrote:
> On Mon, Jun 3, 2024 at 7:11 AM Bertrand Drouvot
> wrote:
> > We’d move the current buffer read and buffer hit counters from the relation
> > stats
> > to the relfilenode stats (while still being able to retrieve them from the
> > pg_s
On Mon, Jun 3, 2024 at 7:11 AM Bertrand Drouvot
wrote:
> The main argument is that we currently don’t have writes counters for
> relations.
> The reason is that we don’t have the relation OID when writing buffers out.
OK.
> Second argument is that this is also beneficial for the "Split index an
that tracking counters at
a common level (i.e relfilenode level instead of table or index level) is
beneficial (avoid storing/allocating space for the same counters in multiple
structs) and sounds more intuitive to me.
Also I think this is open door for new ideas: for example, with relfilenode
sta
Hi Bertrand,
It would be helpful to me if the reasons why we're splitting out
relfilenodestats could be more clearly spelled out. I see Andres's
comment in the thread to which you linked, but it's pretty vague about
why we should do this ("it's not nice") and whether we should do this
("I wonder i
Hi hackers,
Please find attached a POC patch to implement $SUBJECT.
Adding relfilenode statistics has been proposed in [1]. The idea is to allow
tracking dirtied blocks, written blocks,... on a per relation basis.
The attached patch is not in a fully "polished" state yet: there is m
32 matches
Mail list logo
