On Mon, Nov 11, 2024 at 11:06:43AM -0500, Robert Haas wrote:
> But it is unclear to me what sort of tuning we would do based on
> knowing how many of the scans on a certain table or a certain index
> were parallel vs non-parallel. I have not fully reviewed the threads
> linked in the original post;
On Sun, Nov 10, 2024 at 9:05 PM Michael Paquier wrote:
> As hinted on other related threads like around [1], I am so-so about
> the proposal of these numbers at table and index level now that we
> have e7a9496de906 and 5d4298e75f25.
I think the question to which we don't have a clear answer is: f
Le lun. 11 nov. 2024 à 03:05, Michael Paquier a
écrit :
> On Tue, Oct 08, 2024 at 06:24:54PM +0300, Alena Rybakina wrote:
> > yes, I agree with you. Even when I experimented with vacuum settings for
> > database and used my vacuum statistics patch [0] for analyzes , I first
> > looked at this cha
On Tue, Oct 08, 2024 at 06:24:54PM +0300, Alena Rybakina wrote:
> yes, I agree with you. Even when I experimented with vacuum settings for
> database and used my vacuum statistics patch [0] for analyzes , I first
> looked at this change in the number of blocks or deleted rows at the
> database leve
On 07.10.2024 09:34, Guillaume Lelarge wrote:
We need granularity because we have granularity in the config. There
is pg_stat_database because it gives the whole picture and it is
easier to monitor. And then, there is pg_stat_statements to analyze
problematic statements. And finally there is pg
On 07.10.2024 03:41, Michael Paquier wrote:
On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
Maybe I'm not aware of the whole context of the thread and maybe my
questions will seem a bit stupid, but honestly
it's not entirely clear to me how this statistics will help to adjust the
Le lun. 7 oct. 2024 à 02:41, Michael Paquier a écrit :
> On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
> > Maybe I'm not aware of the whole context of the thread and maybe my
> > questions will seem a bit stupid, but honestly
> > it's not entirely clear to me how this statistics
On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
> Maybe I'm not aware of the whole context of the thread and maybe my
> questions will seem a bit stupid, but honestly
> it's not entirely clear to me how this statistics will help to adjust the
> number of parallel workers.
> We may h
Hi!
Finally found some time to work on this. Tests added on v5 patch
(attached).
Maybe I'm not aware of the whole context of the thread and maybe my
questions will seem a bit stupid, but honestly
it's not entirely clear to me how this statistics will help to adjust
the number of parallel worke
Hello,
Le jeu. 5 sept. 2024 à 08:19, Guillaume Lelarge a
écrit :
> Le jeu. 5 sept. 2024 à 07:36, Bertrand Drouvot <
> bertranddrouvot...@gmail.com> a écrit :
>
>> Hi,
>>
>> On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote:
>> > Hi,
>> >
>> > Le mer. 4 sept. 2024 à 16:18, Bertran
Le jeu. 5 sept. 2024 à 07:36, Bertrand Drouvot
a écrit :
> Hi,
>
> On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote:
> > Hi,
> >
> > Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot <
> bertranddrouvot...@gmail.com>
> > a écrit :
> > > What about adding a comment instead of this ex
Hi,
On Wed, Sep 04, 2024 at 04:37:19PM +0200, Guillaume Lelarge wrote:
> Hi,
>
> Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot
> a écrit :
> > What about adding a comment instead of this extra check?
> >
> >
> Done too in v3.
Thanks!
1 ===
+ /*
+* Don't check counts.parallelnum
Hi,
Le mer. 4 sept. 2024 à 16:18, Bertrand Drouvot
a écrit :
> Hi,
>
> On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote:
> > Hi,
> >
> > Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot <
> bertranddrouvot...@gmail.com>
> > a écrit :
> >
> > > What about to get rid of the pgstat_c
Hi,
On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote:
> Hi,
>
> Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot
> a écrit :
>
> > What about to get rid of the pgstat_count_parallel_heap_scan and add an
> > extra
> > bolean parameter to pgstat_count_heap_scan to indicate if
> > c
Le mer. 4 sept. 2024 à 14:58, Bertrand Drouvot
a écrit :
> Hi,
>
> On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote:
> > Le mer. 4 sept. 2024 ą 10:47, Bertrand Drouvot <
> bertranddrouvot...@gmail.com>
> > a écrit :
> >
> > > I don't see a CF entry for this patch. Would you mind
Hi,
On Wed, Sep 04, 2024 at 02:51:51PM +0200, Guillaume Lelarge wrote:
> Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot
> a écrit :
>
> > I don't see a CF entry for this patch. Would you mind creating one so that
> > we don't lost track of it?
> >
> >
> I don't mind adding it, though I don't kno
Hi,
Le mer. 4 sept. 2024 à 10:47, Bertrand Drouvot
a écrit :
> Hi,
>
> On Thu, Aug 29, 2024 at 04:04:05PM +0200, Guillaume Lelarge wrote:
> > Hello,
> >
> > This patch was a bit discussed on [1], and with more details on [2]. It
> > introduces four new columns in pg_stat_all_tables:
> >
> > * pa
Hi,
On Thu, Aug 29, 2024 at 04:04:05PM +0200, Guillaume Lelarge wrote:
> Hello,
>
> This patch was a bit discussed on [1], and with more details on [2]. It
> introduces four new columns in pg_stat_all_tables:
>
> * parallel_seq_scan
> * last_parallel_seq_scan
> * parallel_idx_scan
> * last_paral
Hello,
This patch was a bit discussed on [1], and with more details on [2]. It
introduces four new columns in pg_stat_all_tables:
* parallel_seq_scan
* last_parallel_seq_scan
* parallel_idx_scan
* last_parallel_idx_scan
and two new columns in pg_stat_all_indexes:
* parallel_idx_scan
* last_para
19 matches
Mail list logo
