Hello
While looking at slow queries on pg_stat_statements. I was looking for
percentile fields..
If we are worried about CPU cost, maybe it could be useful to turn in on when
you have a high stddev_exec_time for the query ?
Regards,
De : Adrien Nayrat
Envo
s@postgres=# SELECT * FROM pg_shmem_allocations WHERE
name IS NULL;
name |off| size | allocated_size
--+---+-+
¤| 178095232 | 1923968 |1923968
(1 row)
>From what I understand, the doc is wrong.
Am I right ?
Benoit
[1] https://www.p
Would "NULL for anonymous allocations, since details related to them are
not known." be ok ?
Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi a
écrit :
> At Fri, 11 Dec 2020 14:42:45 +0900, Michael Paquier
> wrote in
> > On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote:
> > > A
Here's a proposal patch.
Le ven. 11 déc. 2020 à 09:58, Benoit Lobréau a
écrit :
> Would "NULL for anonymous allocations, since details related to them are
> not known." be ok ?
>
>
> Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi
> a écrit :
>
>> A
ecover into timelines that branched off earlier than the base
backup." [1][2]
Here is an attempt to fix that.
regards,
Benoit
[1]
https://www.postgresql.org/docs/13/continuous-archiving.html#BACKUP-TIMELINES
[2]
https://www.postgresql.org/docs/12/continuous-archiving.html#BACKU
> Pushed. Thanks!
>
Thank you !
for the lack
> of update of pg_stat_archiver. If it's not the case then we should
> definitely fix that!
>
I tried to do it in the attached patch.
Building the doc worked fine on my computer.
From 350cd7c47d09754ae21f30f260a86e187054257f Mon Sep 17 00:00:00 2001
From: benoit
Date:
Done here : https://commitfest.postgresql.org/32/3012/
Le jeu. 25 févr. 2021 à 15:34, Julien Rouhaud a écrit :
> On Thu, Feb 25, 2021 at 7:25 PM Benoit Lobréau
> wrote:
> >
> > Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud a
> écrit :
> >>
> >> I th
Le lun. 1 mars 2021 à 08:36, Michael Paquier a écrit :
> On Fri, Feb 26, 2021 at 10:03:05AM +0100, Benoit Lobréau wrote:
> > Done here : https://commitfest.postgresql.org/32/3012/
>
> Documenting that properly for the archive command, as already done for
> restore_command, sou
I like the idea !
If it's not too complicated, I'd like to take a stab at it.
Le lun. 1 mars 2021 à 10:16, Julien Rouhaud a écrit :
> On Mon, Mar 1, 2021 at 4:33 PM Benoit Lobréau
> wrote:
> >
> > Le lun. 1 mars 2021 à 08:36, Michael Paquier a
> écrit :
>
Thanks !
Le mar. 2 mars 2021 à 04:10, Julien Rouhaud a écrit :
> On Tue, Mar 2, 2021 at 9:29 AM Michael Paquier
> wrote:
> >
> > On Mon, Mar 01, 2021 at 05:17:06PM +0800, Julien Rouhaud wrote:
> > > Maybe this can be better addressed than with a link in the
> > > documentation. The final outco
Our client confirmed that the more he fetches the more memory is consumed.
The segfault was indeed caused by the absence of LDR_CNTRL.
The tests show that:
* without LDR_CNTRL, we reach 256Mb and segfault ;
* with LDR_CNTRL=MAXDATA=0x1000, we reach 256Mo but there is no
segfault, the program
On 4/8/24 10:05, Andrey M. Borodin wrote:
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Hi thanks for the reminder,
The past month as been hectic for me.
It should calm down
t know how difficult would it be to track/collect this information
> for the whole query.
I am a worried this will be a little too much for me, given the time and
the knowledge gap I have (both in C and PostgreSQL internals). I'll try
to look anyway.
--
Benoit Lobréau
Consultant
http://dalibo.com
convinced the spelling was correct.
--
Benoit Lobréau
Consultant
http://dalibo.com
s.
> Some random thoughts/ideas about how to approach this:
>
> - For parallel workers I think this might be as simple as adding some
> counters into QueryDesc, and update those during query exec (instead of
> just logging stuff directly). I'm not sure if it should be added to
databases. We hope that Postgres 17 will
contain those improvements.
Kind regards,
Benoit
[1] -
https://gist.github.com/benoittgt/ab72dc4cfedea2a0c6a5ee809d16e04d?permalink_comment_id=4972955#gistcomment-4972955
__
Benoit Tigeot
Le jeu. 7 mars 2024 à 15:36, Peter Geoghegan a écrit
icular case.
Finally, the per relation statitics could be combined with system and other
PostgreSQL metrics to identify why the storage is stressed.
If you reach this point, thank you for reading me!
Many thanks to Melanie Plageman for the pointers she shared with us
around the
pgsessions in Paris and her time in general.
--
Benoit Lobréau
Consultant
http://dalibo.com
tement execution: workers
spawned 1, requested 2
STATEMENT: EXPLAIN (ANALYZE) SELECT i, avg(j) FROM test_pql GROUP BY i;
```
[1]
https://www.postgresql.org/message-id/d657df20-c4bf-63f6-e74c-cb85a81d0...@dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.comFrom f7d3dae918df2dbbe7fd18cf48f7ca39d57
e guc, but I would like to keep it at the
LOG level. When I do audits most client are at that level and setting it
to DEBUG1 whould add too much log for them on the long run.
I'll post the corresponding patch asap.
--
Benoit Lobréau
Consultant
http://dalibo.com
bo.com
[2]
https://www.postgresql.org/message-id/flat/6acbe570-068e-bd8e-95d5-00c737b865e8%40gmail.com
--
Benoit Lobréau
Consultant
http://dalibo.comFrom fc71ef40f33f94b0506a092fb5b3dcde6de6d60a Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 2 May 2023 10:08:00 +0200
Subject: [PATCH] Add l
t works.
Is it normal (given the previous message)?
(see password_required2.sql and password_required2.log)
--
Benoit Lobréau
Consultant
http://dalibo.com
--
\c tests_pg16 postgres
You are now connected to database "tests_pg16" as user &quo
RIPTION failure in password_required.log expected for
both superuser and non-superuser?
Is the DROP SUBSCRIPTION success in password_required2.log expected?
(i.e., with password_require=false, the only action a non-superuser can
perform is dropping the subscription. Since they own it, it is
understandable).
--
Benoit Lobréau
Consultant
http://dalibo.com
and form->subpasswordrequired is true
Should there be a test to check if the user executing the query is
superuser? maybe it's handled differently? (I am not very familiar with
the code).
I dont understand (yet?) why I can do ALTER SUBSCRIPTIONs after changing
the ownership to an unpriviledged user (must_use_password should be true
also in that case).
--
Benoit Lobréau
Consultant
http://dalibo.com
re refering to earlier ?
[1]
https://www.postgresql.org/message-id/flat/5dff4caf26f45ce224a33a5e18e110b93a351b2f.camel%40j-davis.com#ff4a06505de317b1ad436b8102a69446
--
Benoit Lobréau
Consultant
http://dalibo.com
On 9/26/23 16:27, Benoit Lobréau wrote:
I will try to come up with a documentation patch.
This is my attempt at a documentation patch.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom a73baa91032fff37ef039168c276508553830f86 Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 26 Sep 2023 18
steps here ].
Warning: if the connection string doesn't contain a password, make sure
to set password_required=false before transferring ownership, otherwise
it will start failing."
Ok, I will do it that way. Would you prefer this section to be in the
ALTER SUBSCRIPTION on the CREATE SUB
/pgsql_tmp/pgsql_tmp138850.23", size 14
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp138850.22", size
122880 => Second sort
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp138850.21", size 14
--
Benoit Lobréau
Consultant
http://dalibo.com
ion in "Logical Replication > Subscription" with
the text you suggested and links in the CREATE / ALTER SUBSRIPTION commands.
Is it better ?
--
Benoit Lobréau
Consultant
http://dalibo.comFrom f3f1b0ce8617971b173ea901c9735d8357955aa2 Mon Sep 17 00:00:00 2001
From: benoit
Date: Thu
On Tue, Aug 30, 2022 at 12:46 AM Nathan Bossart
wrote:
> I would advise that you create a commitfest entry for your patch so that it
> isn't forgotten.
>
Ok done, https://commitfest.postgresql.org/39/3856/ (is that fine if I
added you as a reviewer ?)
and thanks for the added links in the patch
help and motivation boost.
(sorry for the spam, I had to resend the mail to the list)
--
Benoit Lobréau
Consultant
http://dalibo.comFrom 940e1d1149f33ea00e7a0a688da67f492f6d Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 26 Aug 2024 13:48:44 +0200
Subject: [PATCH] Add logging for
ched | 4
Thanks to: Jehan-Guillaume de Rorthais, Guillaume Lelarge and Franck
Boudehen for the help and motivation boost.
---
Benoit Lobréau
Consultant
http://dalibo.comFrom cabe5e8ed2e88d9cf219161394396ebacb33a5a0 Mon Sep 17 00:00:00 2001
From: benoit
Date: Wed, 28 Aug 2024 02:27:13 +0200
Subject:
check executions.)
On 8/28/24 17:10, Benoit Lobréau wrote:
Hi hackers,
This patch introduces four new columns in pg_stat_database:
* parallel_worker_planned
* parallel_worker_launched
* parallel_maint_worker_planned
* parallel_maint_worker_launched
The intent is to help administrators evaluate
Hi,
This new version avoids updating the stats for non parallel queries.
I noticed that the tests are still not stable. I tried using tenk2
but fail to have stable plans. I'd love to have pointers on that front.
--
Benoit Lobréau
Consultant
http://dalibo.co
es().
Back to the drawing board...
--
Benoit Lobréau
Consultant
http://dalibo.com
-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.com
Here is an updated patch fixing the aforementionned problems
with tests and vacuum stats.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom 1b52f5fb4e977599b8925c69193d31148042ca7d Mon Sep 17 00:00:00 2001
From: benoit
Date: Wed, 28 Aug 2024 02:27:13 +0200
Subject: [PATCH] Adds four parallel
Data API of AWS RDS
<https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html> ?
I’m unfortunately not a python developer, focusing on JavaScript client and
server-side myself, but I hope I’m not the only one who’s like to do this!
Thanks for any feedback/pointers!
Benoit
On 10/14/24 22:42, Alena Rybakina wrote:
Attached is the correct version of the patch.
Thank you, it's a lot cleaner that way.
I'll add this asap.
--
Benoit Lobréau
Consultant
http://dalibo.com
ded before posting
the result here.
I have hopes to finish it this week.
--
Benoit Lobréau
Consultant
http://dalibo.com
This is a rebased version.
I have split queries, vacuum and index creation in different patches.
I have also split the declartion that are in common with the
pg_stat_database patch.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom cfa426a080ca2d0c484ac8f5201800bd6434 Mon Sep 17 00:00:00
rsion, I modified it to:
* have the same wording in the doc and code (planned => to_launch)
* split de declaration from the rest (and have the same code as the
parallel worker logging patch)
--
Benoit Lobréau
Consultant
http://dalibo.comFrom ab9aa1344f974348638dd3898c944f3d5253374d Mon Sep 17
On 10/15/24 09:52, Benoit Lobréau wrote:
Thank you, it's a lot cleaner that way.
I'll add this asap.
This is an updated version with the suggested changes.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom b9bf7c0fa967c72972fd77333a768dfe89d91765 Mon Sep 17 00:00:00 2001
From: be
On 11/11/24 02:51, Michael Paquier wrote:
Okidoki, applied. If tweaks are necessary depending on the feedback,
like column names, let's tackle things as required. We still have a
good chunk of time for this release cycle.
--
Michael
Thanks !
--
Benoit Lobréau
Consultant
http://dalibo.com
amp; brin) and vacuum cleanup is not commited
yet since it's not a common occurence. I implemented it in separate
counters.
--
Benoit Lobréau
Consultant
http://dalibo.com
for coherence sake. I prefer "planned"
but english is clearly not my strong suit and I assumed it meant that
the number of worker planned could change before execution. I just
checked in parallel.c and I don't think it's the case, could it be done
elsewhere ?
--
Benoit Lob
Here is a new version that fixes the aforementioned problems.
If this patch is accepted in this form, the counters could be used for
the patch in pg_stat_database. [1]
[1]
https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
bd_VbUt6K6xn8P7X%2B_dZqKw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/flat/CAECtzeXXuMkw-RVGTWvHGOJsmFdsRY%2BjK0ndQa80sw46y2uvVQ%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/8123423a-f041-4f4c-a771-bfd96ab235b0%40dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.com
objections or
comments, feel free.
Found a few more things, but overall it was fine. Here is what I have
staged on my local branch.
--
Michael
Hi,
I just reread the patch.
Thanks for the changes. It looks great.
--
Benoit Lobréau
Consultant
http://dalibo.com
This is just a rebase.
As stated before, I added some information to the error message for
parallel queries as an experiment. It can be removed, if you re not
convinced.
---
Benoit Lobréau
Consultant
http://dalibo.comFrom 7e63f79226357f2fe84acedb950e64383e582b17 Mon Sep 17 00:00:00 2001
From
the same way as other
GUCs with an options list. I ended up just making those changes
in v8.
Besides that, I think this is ready for committer.
Thank you for your time and advice on this.
--
Benoit Lobréau
Consultant
http://dalibo.com
I did some additional testing with this command within transactions.
I had the "BEGIN; ALTER INDEX; EXPLAIN; ROLLBACK;" scenario in mind, but
didn't realise we acquire an AccessExclusiveLock on the index. Therefore, it's
not possible to change the visibility within a single transaction
unless
Here is an updated patch to save you some time.
--
Benoit Lobréau
Consultant
http://dalibo.com
From 5d89ca0a36e98d1e5be858166a8394c09e0fa129 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?=
Date: Tue, 5 Nov 2024 17:59:44 +0100
Subject: [PATCH] doc: explain pgstatindex
corresponds to the logical order we would have
just after
a REINDEX.
--
Benoit Lobréau
Consultant
http://dalibo.com
25.3.8. Tips and Examples
25.3.9. Caveats
Note: As I mentioned to you privately, I made a mistake and broke the
thread. I’ve added the new thread to the commit fest. Here is a link to
the old one to help others follow the conversation:
https://www.postgresql.org/message-id/flat/CAKFQuwaS6DtSde4TWpk133mfaQbgh8d%2BPkk0kDN%3D6jf6qEWbvQ%40mail.gmail.com
--
Benoit Lobréau
Consultant
http://dalibo.com
Hi,
Thank you for the patch! I've had a need for this feature several times,
so I appreciate the work you’ve put into it.
I like the new name VISIBLE/INVISIBLE and the fact that it's a separate flag in
pg_index (it's easy to monitor).
I don’t feel qualified to provide an opinion on the code itse
---+
i | integer | yes | i
primary key, btree, for table "public.repli", invalid, invisible
From bf3f11e5e88a30a9c1affd9678dadec9bc236351 Mon Sep 17 00:00:00 2001
From: benoit
Date: Fri, 24 Jan 2025 16:12:45 +0100
Subject: [PATCH 2/3] Add the invisible tag for indexes in \d
-
On Fri, Jan 24, 2025 at 11:32 AM Benoit Lobréau
wrote:
> The completion for the INVISIBLE / VISIBLE keyword is missing in psql.
I think this should to the trick ?
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index 81cbf10aa28..43ea8e55fd0 100644
--- a/src/
would want to have the information for only a portion of the
functionality's usage (even if it's the most important).
--
Benoit Lobréau
Consultant
http://dalibo.comFrom b99dc5c1c549921ed2ac054db4e8c5398543dfc4 Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 8 Oct 2024 12:39:41 +0200
ey had the same density but one had no fragmentation while the
other had 100%. He got an execution time of ~90ms (0 frag) vs ~340ms
100% frag).
I get similar result with my laptor (except my disk is significantly
worse: ~152ms vs ~833ms).
Here are the scripts.
--
Benoit Lobréau
C
e Hot Backup
25.3.6. Recovering Using a Continuous Archive Backup
25.3.7. Timelines
25.3.8. Tips and Examples
25.3.9. Caveats
--
Benoit Lobréau
Consultant
http://dalibo.com
e), collect the logs and generate a report
for the said period to have a broad overview of what is happenning.
I attached patches that implemented both your suggestions (I regrouped
all the utilities together).
Thank you !
--
Benoit Lobréau
Consultant
http://
If we decide
to strip them, I will revert it to log_parallel_query_workers.
>> I don't think "failure" is a good name for the setting as it's
>> a bit too harsh. What we really have is a "shortage" of
>> workers.
I agree that "failure" is too harsh. The term "shortage" better describes
the situation.
Note: I added Tomas Vondra to the recipients of the email since he advised
me on this topic initially and might have an opinion on this.
--
Benoit Lobréau
Consultant
http://dalibo.com
On 2/20/25 4:40 PM, David Steele wrote:
Benoit -- this was your idea. Did you want to submit a patch yourself?
Here is an attempt at that. I kept the wording I used above. Is it fine
to repeat the whole ereport block twice?
--
Benoit Lobréau
Consultant
http://dalibo.com
From
file */".
Thank you Michael and David.
I never paid attention to thoses...
--
Benoit Lobréau
Consultant
http://dalibo.com
From 9a12cad29afb86f2277bf76bc53757702715afd5 Mon Sep 17 00:00:00 2001
From: benoit
Date: Fri, 21 Feb 2025 14:09:56 +0100
Subject: [PATCH] Adjust logging for invalid recovery tim
ities)?
--
Benoit Lobréau
Consultant
http://dalibo.com
.
Is there a specific way todo this?
--
Benoit Lobréau
Consultant
http://dalibo.com
From 35dd8db22c997e78ba92f63ffca3022b435d7304 Mon Sep 17 00:00:00 2001
From: benoit
Date: Fri, 21 Feb 2025 14:09:56 +0100
Subject: [PATCH] Adjust logging for invalid recovery timeline
The original message
(or me in a few month) it might be useful ?
--
Benoit Lobréau
Consultant
http://dalibo.com
4 | 7.0171877| 8.43500897435
as Amit pointed out, we will share a new test script soon
that uses the SQL API xxx_get_changes() to test. It would be great if you could
verify the performance using the updated script as well.
Will do.
--
Benoit Lobréau
Consultant
http://dalibo.com
| 3,57678295 | 18,67676928162
2000 | 7,0171877 | 6,4713304| 8,43500897435
I'll try to run test2.pl later (right now it fails).
hope this helps.
--
Benoit Lobréau
Consultant
http://dalibo.com
cache_inval_bug_v1.ods
Description: applic
ging in _gin_end_parallel().
You’ll find the updated patch attached.
[1] https://commitfest.postgresql.org/patch/5212/
--
Benoit
From 59cd090e78a5833b901ad662d6ae1ae936c3172d Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 8 Oct 2024 12:39:41 +0200
Subject: [PATCH 1/3] Add a guc for parallel wo
5.2.8. Tips and Examples
25.2.9. Caveats
25.3. File System Level Backup
I slightly modified section 25.2.1 and 25.3 as proposed.
--
Benoit Lobréau
Consultant
http://dalibo.com
From 16813b396a45c4061b5c2d21a9091e3fb372567c Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 15 Apr 2025 15:25:08
72 matches
Mail list logo
