On Mon, Jun 3, 2024 at 9:10 AM Justin Pryzby wrote:
>
> On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> > Hi Justin,
> >
> > Thanks for the patch and the work on it. In reviewing the basic
> > feature, I think this is something that has utility and is worthwhile
> > at the hi
po 3. 6. 2024 v 16:10 odesílatel Justin Pryzby
napsal:
> On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> > Hi Justin,
> >
> > Thanks for the patch and the work on it. In reviewing the basic
> > feature, I think this is something that has utility and is worthwhile
> > at the
On Thu, May 30, 2024 at 10:59:06AM -0700, David Christensen wrote:
> Hi Justin,
>
> Thanks for the patch and the work on it. In reviewing the basic
> feature, I think this is something that has utility and is worthwhile
> at the high level.
Thanks for looking.
> A few more specific notes:
>
>
Hi Justin,
Thanks for the patch and the work on it. In reviewing the basic
feature, I think this is something that has utility and is worthwhile
at the high level.
A few more specific notes:
The pg_namespace_size() function can stand on its own, and probably
has some utility for the released Po
2024-01 Commitfest.
Hi, This patch had a CF status of "Ready for Committer", but the
thread has been inactive for 5+ months.
Since the last post from Justin said "hoping to receive some feedback"
I have changed the CF status back to "Needs Review" [1].
==
[1] https://commitfest.postgresql.or
On Thu, Dec 15, 2022 at 10:13:23AM -0600, Justin Pryzby wrote:
> This patch record was "closed for lack of interest", but I think what's
> actually needed is committer review of which approach to take.
On Tue, Aug 01, 2023 at 09:54:34AM +0200, Daniel Gustafsson wrote:
> > On 24 May 2023, at 23:05,
> On 24 May 2023, at 23:05, Justin Pryzby wrote:
> I'm planning to set this patch as ready
This is marked RfC so I'm moving this to the next CF, but the patch no longer
applies so it needs a rebase.
--
Daniel Gustafsson
I added documentation for the SQL functions in 001.
And updated to say 17
I'm planning to set this patch as ready - it has not changed
significantly in 18 months. Not for the first time, I've implemented a
workaround at a higher layer.
--
Justin
>From 917e5e36d14018b6de457ba9eafe8936c0e88c3
On Thu, Dec 15, 2022 at 10:13:23AM -0600, Justin Pryzby wrote:
> Rebased on c727f511b.
Rebased on 30a53b792.
With minor changes including fixes to an intermediate patch.
> This patch record was "closed for lack of interest", but I think what's
> actually needed is committer review of which approa
čt 15. 12. 2022 v 17:13 odesílatel Justin Pryzby
napsal:
> Rebased on c727f511b.
>
> This patch record was "closed for lack of interest", but I think what's
> actually needed is committer review of which approach to take.
>
> - add backend functions but do not modify psql ?
> - add to psql slas
Rebased on c727f511b.
This patch record was "closed for lack of interest", but I think what's
actually needed is committer review of which approach to take.
- add backend functions but do not modify psql ?
- add to psql slash-plus commnds ?
- introduce psql double-plus commands for new options
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
rebased
>From 1e560284832c157ca18a43f44b090e5b35b0cfb3 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH v8 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
src/backend/utils/adt/dbsize.c | 130
Rebased
>From 4d88986706e334e2dccc6f576139342c102033f8 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
src/backend/utils/adt/dbsize.c | 130 +++
Hi
I like this feature, but I don't like the introduction of double + too
much. I think it is confusing.
Is it really necessary? Cannot be enough just reorganization of \dn and
\dn+.
Regards
Pavel
pá 14. 1. 2022 v 17:35 odesílatel Justin Pryzby
napsal:
> Rebased before Julian asks.
>
Rebased before Julian asks.
>From cf57143c85a2a6088fe6038e6d41771fd60aae34 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subject: [PATCH 1/4] Add pg_am_size(), pg_namespace_size() ..
See also: 358a897fa, 528ac10c7
---
src/backend/utils/adt/dbsize.c | 130 +++
Remove bogus ACL check for AMs.
Rebased on cf0cab868.
Use ForkNumber rather than int.
Update comments and commit message.
Also move the Size column of \l and \dt
>From a1d33780e4c61a7bdb64ee6ab5c248e1175a3efd Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 13 Jul 2021 21:25:48 -0500
Subjec
út 28. 9. 2021 v 4:46 odesílatel Justin Pryzby
napsal:
> On Fri, Sep 17, 2021 at 12:05:04PM +0200, Pavel Stehule wrote:
> > I can live with the proposed patch, and I understand why ++ was
> > introduced. But I am still not sure it is really user friendly. I prefer
> to
> > extend \dA and \dn wit
On Fri, Sep 17, 2021 at 12:05:04PM +0200, Pavel Stehule wrote:
> I can live with the proposed patch, and I understand why ++ was
> introduced. But I am still not sure it is really user friendly. I prefer to
> extend \dA and \dn with some columns (\dA has only two columns and \dn has
> two columns
pá 17. 9. 2021 v 11:10 odesílatel Justin Pryzby
napsal:
> On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> > Besides, schemas are not physical, but logical containers. So I see a
> point in
> > measuring the storage used in a certain tablespace, but not so much by
> all objects
>
On Thu, 2021-07-15 at 20:16 -0500, Justin Pryzby wrote:
> On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> > Besides, schemas are not physical, but logical containers. So I see a
> > point in
> > measuring the storage used in a certain tablespace, but not so much by all
> > object
On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> Besides, schemas are not physical, but logical containers. So I see a point
> in
> measuring the storage used in a certain tablespace, but not so much by all
> objects
> in a certain schema. It might be useful for accounting purpos
22 matches
Mail list logo