Hi Tomas and Justin,
On 2021/07/27 4:26, Tomas Vondra wrote:
Hi,
I've pushed the last version of the fix, including the regression tests etc.
Backpatch to 14, where \dX was introduced.
Thank you!
Regards,
Tatsuro Yamada
Hi,
I've pushed the last version of the fix, including the regression tests
etc. Backpatch to 14, where \dX was introduced.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Tomas and Justin,
On 2021/06/07 4:47, Tomas Vondra wrote:
Here's a slightly more complete patch, tweaking the regression tests a
bit to detect this.
I tested your patch on PG14beta2 and PG15devel.
And they work fine.
===
All 209 tests passed.
===
Hi,
Here's a slightly more complete patch, tweaking the regression tests a
bit to detect this.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 2abf255798..eba659705e 100644
On 5/30/21 7:24 PM, Justin Pryzby wrote:
> On Wed, Jan 20, 2021 at 11:00:50PM +0100, Tomas Vondra wrote:
>> Thanks, I've pushed this. I had to tweak the regression tests a bit, for two
>> reasons:
>
> \dX isn't checking schema visibility rules, so accidentally shows stats
> objects
> outside
On Wed, Jan 20, 2021 at 11:00:50PM +0100, Tomas Vondra wrote:
> Thanks, I've pushed this. I had to tweak the regression tests a bit, for two
> reasons:
\dX isn't checking schema visibility rules, so accidentally shows stats objects
outside of the search path. I noticed after installing the
Hi Tomas and hackers,
On 2021/01/21 7:00, Tomas Vondra wrote:
I created patches and my test results on PG10, 11, 12, and 14 are fine.
0001:
- Fix query to use pg_statistic_ext only
- Replace statuses "required" and "built" with "defined"
- Remove the size columns
- Fix
On 1/20/21 7:41 AM, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/20 11:35, Tatsuro Yamada wrote:
Apologies for all the extra work - I haven't realized this flaw when
pushing for showing more stuff :-(
Don't worry about it. We didn't notice the problem even when viewed by
multiple
people
1cfc1e57a9daa Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Wed, 20 Jan 2021 15:09:27 +0900
Subject: [PATCH 1/2] psql \dX: list extended statistics objects take2
The new command lists extended statistics objects.
All past releases with extended statistics are supported.
Author: Tatsuro Yama
Hi Tomas,
On 2021/01/19 11:52, Tomas Vondra wrote:
I'm going to create the WIP patch to use the above queriy.
Any comments welcome. :-D
Yes, I think using this simpler query makes sense. If we decide we need
something more elaborate, we can improve that by in future PostgreSQL versions
Hi,
The above query is so simple so that we would better to use the following query:
# This query works on PG10 or later
SELECT
es.stxnamespace::pg_catalog.regnamespace::text AS "Schema",
es.stxname AS "Name",
pg_catalog.format('%s FROM %s',
(SELECT
On 1/19/21 1:44 AM, Tatsuro Yamada wrote:
Hi Tomas,
As for how to deal with this, I can think of about three ways:
1) simplify the command to only print information from
pg_statistic_ext (so on information about which stats are built or
sizes)
2) extend pg_stats_ext with necessary
Hi Tomas,
As for how to deal with this, I can think of about three ways:
1) simplify the command to only print information from pg_statistic_ext (so on
information about which stats are built or sizes)
2) extend pg_stats_ext with necessary information (e.g. sizes)
3) create a new system
On 1/18/21 8:31 AM, Tatsuro Yamada wrote:
Hi Tomas and Shinoda-san,
On 2021/01/17 23:31, Tomas Vondra wrote:
On 1/17/21 3:01 AM, Tomas Vondra wrote:
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be
Hi Justin,
On 2021/01/18 1:52, Justin Pryzby wrote:
On Sun, Jan 17, 2021 at 03:31:57PM +0100, Tomas Vondra wrote:
I've reverted the commit - once we find the right way to handle this, I'll
get it committed again.
Please consider these doc changes for the next iteration.
commit
Hi Tomas and Shinoda-san,
On 2021/01/17 23:31, Tomas Vondra wrote:
On 1/17/21 3:01 AM, Tomas Vondra wrote:
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
Hi Tomas,
On 2021/01/17 8:32, Tomas Vondra wrote:
I've pushed this, keeping the "requested". If we decide that some other term is
a better choice, we can tweak that later of course.
Thanks Tatsuro-san for the patience!
Thanks for taking the time to review the patches.
I believe this feature
Hi Julien,
On 2021/01/15 17:47, Julien Rouhaud wrote:
Hello Yamada-san,
I reviewed the patch and don't have specific complaints, it all looks good!
I'm however thinking about the "requested" status. I'm wondering if it could
lead to people think that an ANALYZE is scheduled and will happen
On Sun, Jan 17, 2021 at 03:31:57PM +0100, Tomas Vondra wrote:
> I've reverted the commit - once we find the right way to handle this, I'll
> get it committed again.
Please consider these doc changes for the next iteration.
commit 1a69f648ce6c63ebb37b6d8ec7c6539b3cb70787
Author: Justin Pryzby
On 1/17/21 3:01 AM, Tomas Vondra wrote:
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability
to access pg_statistics_ext_data.
Is this the expected behavior?
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
access pg_statistics_ext_data.
Is this the expected behavior?
Hmmm, that's a good point. Bummer we haven't
PostgreSQL Hackers
Subject: Re: list of extended statistics on psql
On 1/15/21 5:19 PM, Tomas Vondra wrote:
>
>
> On 1/15/21 9:47 AM, Julien Rouhaud wrote:
>> On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
>>> Hi Tomas,
>>>
>>> On 202
On 1/15/21 5:19 PM, Tomas Vondra wrote:
On 1/15/21 9:47 AM, Julien Rouhaud wrote:
On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/13 7:48, Tatsuro Yamada wrote:
On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
On
On 1/15/21 9:47 AM, Julien Rouhaud wrote:
> On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
>> Hi Tomas,
>>
>> On 2021/01/13 7:48, Tatsuro Yamada wrote:
>>> On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
> On 2021/01/09 9:01, Tomas
On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
> Hi Tomas,
>
> On 2021/01/13 7:48, Tatsuro Yamada wrote:
> > On 2021/01/12 20:08, Tomas Vondra wrote:
> > > On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
> > > > On 2021/01/09 9:01, Tomas Vondra wrote:
> > > ...>
> > > > > While working
Hi Tomas,
On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/09 9:01, Tomas Vondra wrote:
...>
While working on that, I realized that 'defined' might be a bit
ambiguous, I initially thought it means 'NOT NULL' (which it does not).
I
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/09 9:01, Tomas Vondra wrote:
...>
While working on that, I realized that 'defined' might be a bit
ambiguous, I initially thought it means 'NOT NULL' (which it does not).
I propose to change it to 'requested' instead. Tatsuro, do
atsuro Yamada
>From 3d2f4ef2ecba9fd7987df665237add6fc4ec03c1 Mon Sep 17 00:00:00 2001
From: Tatsuro Yamada
Date: Thu, 7 Jan 2021 14:28:20 +0900
Subject: [PATCH 1/2] psql \dX: list extended statistics objects
The new command lists extended statistics objects, possibly with their
sizes. All past re
d' might be a bit
ambiguous, I initially thought it means 'NOT NULL' (which it does not).
I propose to change it to 'requested' instead. Tatsuro, do you agree, or
do you think 'defined' is better?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
On 1/8/21 12:52 AM, Tatsuro Yamada wrote:
Hi,
On 2021/01/08 0:56, Tomas Vondra wrote:
On 1/7/21 3:47 PM, Alvaro Herrera wrote:
On 2021-Jan-07, Tomas Vondra wrote:
On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
I overlooked the check for MCV in the logic building query
because I created the
Hi,
On 2021/01/08 0:56, Tomas Vondra wrote:
On 1/7/21 3:47 PM, Alvaro Herrera wrote:
On 2021-Jan-07, Tomas Vondra wrote:
On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
I overlooked the check for MCV in the logic building query
because I created the patch as a new feature on PG14.
I'm not sure
On 1/7/21 3:47 PM, Alvaro Herrera wrote:
On 2021-Jan-07, Tomas Vondra wrote:
On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
I overlooked the check for MCV in the logic building query
because I created the patch as a new feature on PG14.
I'm not sure whether we should do back patch or not.
On 2021-Jan-07, Tomas Vondra wrote:
> On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
> > I overlooked the check for MCV in the logic building query
> > because I created the patch as a new feature on PG14.
> > I'm not sure whether we should do back patch or not. However, I'll
> > add the check on the
On 1/7/21 1:46 AM, Tatsuro Yamada wrote:
Hi Tomas,
Thanks, and Happy new year to you too.
I almost pushed this, but I have one more question. listExtendedStats
first checks the server version, and errors out for pre-10 servers.
Shouldn't the logic building query check the server version
Hi Tomas,
Thanks, and Happy new year to you too.
I almost pushed this, but I have one more question. listExtendedStats first checks the
server version, and errors out for pre-10 servers. Shouldn't the logic building query
check the server version too, to decide whether to check the MCV
On 1/5/21 5:26 AM, Tatsuro Yamada wrote:
Hi,
I rebased the patch set on the master (7e5e1bba03), and the regression
test is good. Therefore, I changed the status of the patch: "needs
review".
Happy New Year!
I rebased my patches on HEAD.
Please find attached files. :-D
Thanks, and
Hi,
I rebased the patch set on the master (7e5e1bba03), and the regression
test is good. Therefore, I changed the status of the patch: "needs review".
Happy New Year!
I rebased my patches on HEAD.
Please find attached files. :-D
Thanks,
Tatsuro Yamada
From
Hi Tomas and hackers,
I don't prefer a long name but I'll replace the name with it to be clearer.
For example, s/N_size/Ndistinct_size/.
Please find attached patcheds:
- 0001: Replace column names
- 0002: Recreate regression test based on 0001
I rebased the patch set on the master
Hi Tomas,
Thanks for your comments and also revising patches.
On 2020/11/16 3:22, Tomas Vondra wrote:
It's better to always post the whole patch series, so that cfbot can
test it properly. Sending just 0003 separately kind breaks that.
I now understand how "cfbot" works so that I'll take
Thanks,
It's better to always post the whole patch series, so that cfbot can
test it properly. Sending just 0003 separately kind breaks that.
Also, 0003 seems to only tweak the .sql file, not the expected output,
and there actually seems to be two places that mistakenly use \dx (so
listing
Hi,
2) The test is failing intermittently because it's executed in parallel
with stats_ext test, which is also creating extended statistics. So
depending on the timing the \dX may list some of the stats_ext stuff.
I'm not sure what to do about this. Either this part needs to be moved
to a
Hi Tomas,
I took a look at this today, and I think the code is ready, but the
regression test needs a bit more work:
Thanks for taking your time. :-D
1) It's probably better to use somewhat more specific names for the
objects, especially when created in public schema. It decreases the
Hi,
I took a look at this today, and I think the code is ready, but the
regression test needs a bit more work:
1) It's probably better to use somewhat more specific names for the
objects, especially when created in public schema. It decreases the
chance of a collision with other tests (which may
Hi,
I addressed it, so I keep the size of extended stats with the unit.
Changes:
- Use pg_size_pretty to show the size of extended stats by \dX+
I rebased the patch on the head and also added tab-completion.
Any feedback is welcome.
Preparing for tests:
===
create
Hi Tomas,
On 2020/10/29 4:06, Tomas Vondra wrote:
On Wed, Oct 28, 2020 at 03:07:56PM +0900, Tatsuro Yamada wrote:
Hi Michael-san and Hackers,
On 2020/09/30 15:19, Michael Paquier wrote:
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
Could you provide at least a rebased
Hi Tomas,
On 2020/10/29 4:07, Tomas Vondra wrote:
On Wed, Oct 28, 2020 at 04:20:25PM +0900, Tatsuro Yamada wrote:
Hi,
Results of \dX and \dX+:
postgres=# \dX
List of extended statistics
Schema | Name | Definition |
On Wed, Oct 28, 2020 at 04:20:25PM +0900, Tatsuro Yamada wrote:
Hi,
Results of \dX and \dX+:
postgres=# \dX
List of extended statistics
Schema | Name | Definition | N_distinct | Dependencies | Mcv
On Wed, Oct 28, 2020 at 03:07:56PM +0900, Tatsuro Yamada wrote:
Hi Michael-san and Hackers,
On 2020/09/30 15:19, Michael Paquier wrote:
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
Could you provide at least a rebased version of the patch? The CF bot
is complaning here.
Hi,
Results of \dX and \dX+:
postgres=# \dX
List of extended statistics
Schema | Name | Definition | N_distinct | Dependencies | Mcv
-+---+-++--+-
Hi Michael-san and Hackers,
On 2020/09/30 15:19, Michael Paquier wrote:
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
Could you provide at least a rebased version of the patch? The CF bot
is complaning here.
Not seeing this answered after two weeks, I have marked the
Hi Michael-san and Hackers,
On 2020/09/30 15:19, Michael Paquier wrote:
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
Could you provide at least a rebased version of the patch? The CF bot
is complaning here.
Not seeing this answered after two weeks, I have marked the
On Thu, Sep 17, 2020 at 02:55:31PM +0900, Michael Paquier wrote:
> Could you provide at least a rebased version of the patch? The CF bot
> is complaning here.
Not seeing this answered after two weeks, I have marked the patch as
RwF for now.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 03, 2020 at 08:45:17AM +0900, Tatsuro Yamada wrote:
> I try to summarize the discussion so far.
Could you provide at least a rebased version of the patch? The CF bot
is complaning here.
--
Michael
signature.asc
Description: PGP signature
Hi,
>> I wonder if trying to list info about all stats from the statistics
>> object in a single line is necessary. Maybe we should split the info
>> into one line per statistics, so for example
>>
>> CREATE STATISTICS s (mcv, ndistinct, dependencies) ON ...
>>
po 31. 8. 2020 v 18:32 odesílatel Tomas Vondra
napsal:
> On Mon, Aug 31, 2020 at 12:18:09PM -0400, Alvaro Herrera wrote:
> >On 2020-Aug-31, Tomas Vondra wrote:
> >
> >> I wonder if trying to list info about all stats from the statistics
> >> object in a single line is necessary. Maybe we should
On Mon, Aug 31, 2020 at 12:18:09PM -0400, Alvaro Herrera wrote:
On 2020-Aug-31, Tomas Vondra wrote:
I wonder if trying to list info about all stats from the statistics
object in a single line is necessary. Maybe we should split the info
into one line per statistics, so for example
CREATE
On 2020-Aug-31, Tomas Vondra wrote:
> I wonder if trying to list info about all stats from the statistics
> object in a single line is necessary. Maybe we should split the info
> into one line per statistics, so for example
>
> CREATE STATISTICS s (mcv, ndistinct, dependencies) ON ...
>
>
On Mon, Aug 31, 2020 at 10:28:38AM -0400, Alvaro Herrera wrote:
On 2020-Aug-30, Tomas Vondra wrote:
On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
> I wonder how to report that. Knowing that psql \-commands are not meant
> for anything other than human consumption, maybe
On Mon, Aug 31, 2020 at 10:58:11AM -0400, Tom Lane wrote:
Alvaro Herrera writes:
If we do put each type in its own row -- at least "logical" row, say
string_agg(unnest(array_of_types), '\n') -- then we can put the size of each
type
in a separate column with string_agg(unnest(array_of_sizes),
Alvaro Herrera writes:
> If we do put each type in its own row -- at least "logical" row, say
> string_agg(unnest(array_of_types), '\n') -- then we can put the size of each
> type
> in a separate column with string_agg(unnest(array_of_sizes), '\n')
> statname | definition| type
On 2020-Aug-30, Tomas Vondra wrote:
> On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
> > I wonder how to report that. Knowing that psql \-commands are not meant
> > for anything other than human consumption, maybe we can use a format()
> > string that says "built: %d bytes"
On Thu, Aug 27, 2020 at 07:53:23PM -0400, Alvaro Herrera wrote:
> +1 for the general idea, and +1 for \dX being the syntax to use
>
> IMO the per-type columns should show both the type being enabled as
> well as it being built.
>
> (How many more stat types do we expect -- Tomas? I wonder if
On 2020/08/31 1:59, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
I wonder how to report that. Knowing that psql \-commands are not meant
for anything other than human consumption, maybe we can use a format()
string that says "built: %d
Hi Alvaro,
IMO the per-type columns should show both the type being enabled as
well as it being built.
Hmm. I'm not sure how to get the status (enabled or disabled) of
extended stats. :(
Could you explain it more?
pg_statistic_ext_data.stxdndistinct is not null if the stats have been
built.
Tomas Vondra writes:
> On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
>> I wonder how to report that. Knowing that psql \-commands are not meant
>> for anything other than human consumption, maybe we can use a format()
>> string that says "built: %d bytes" when \dX+ is used (for
On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:
On 2020-Aug-30, Tomas Vondra wrote:
On Sat, Aug 29, 2020 at 06:43:47PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-29, Tomas Vondra wrote:
> > Also, it might be useful to show the size of the statistics built, just
> > like we
On 2020-Aug-30, Tomas Vondra wrote:
> On Sat, Aug 29, 2020 at 06:43:47PM -0400, Alvaro Herrera wrote:
> > On 2020-Aug-29, Tomas Vondra wrote:
> > > Also, it might be useful to show the size of the statistics built, just
> > > like we show for \d+ etc.
> >
> > \dX+ I suppose?
>
> Right. I've
On Sat, Aug 29, 2020 at 06:43:47PM -0400, Alvaro Herrera wrote:
On 2020-Aug-29, Tomas Vondra wrote:
But if we want the
output to show both what was requested and which types were actually
built, that'll effectively double the number of columns needed :-(
I was thinking it would be one column
On 2020-Aug-29, Tomas Vondra wrote:
> But if we want the
> output to show both what was requested and which types were actually
> built, that'll effectively double the number of columns needed :-(
I was thinking it would be one column per type showing either disabled or
enabled
or built. But
On Thu, Aug 27, 2020 at 11:26:17PM -0400, Alvaro Herrera wrote:
On 2020-Aug-28, Tatsuro Yamada wrote:
> IMO the per-type columns should show both the type being enabled as
> well as it being built.
Hmm. I'm not sure how to get the status (enabled or disabled) of
extended stats. :(
Could you
On Thu, Aug 27, 2020 at 07:53:23PM -0400, Alvaro Herrera wrote:
+1 for the general idea, and +1 for \dX being the syntax to use
IMO the per-type columns should show both the type being enabled as
well as it being built.
(How many more stat types do we expect -- Tomas? I wonder if having one
On 2020-Aug-28, Tatsuro Yamada wrote:
> > IMO the per-type columns should show both the type being enabled as
> > well as it being built.
>
> Hmm. I'm not sure how to get the status (enabled or disabled) of
> extended stats. :(
> Could you explain it more?
pg_statistic_ext_data.stxdndistinct is
Hi Alvaro!
It's been ages since we created a progress reporting feature together. :-D
+1 good idea
+1 that's a good idea. Please add it to the next commitfest!
+1 for the general idea, and +1 for \dX being the syntax to use
Thank you for voting!
IMO the per-type columns should show
+1 for the general idea, and +1 for \dX being the syntax to use
IMO the per-type columns should show both the type being enabled as
well as it being built.
(How many more stat types do we expect -- Tomas? I wonder if having one
column per type is going to scale in the long run.)
Also, the stat
Hi Julien!
Thanks also for the documentation and regression tests. This overall looks
good, I just have a two comments:
Thank you for reviewing the patch! :-D
- there's a whitespace issue in the documentation part:
add_list_extended_stats_for_psql_by_dX_command.patch:10: tab in
Hi Yamada-san,
On Thu, Aug 27, 2020 at 03:13:09PM +0900, Tatsuro Yamada wrote:
>
> I re-read a help message of \d* commands and realized it's better to
> use "\dX".
> There are already cases where the commands differ due to differences
> in case, so I did the same way. Please find attached
Hi Julien and Pavel!
How about using \dX rather than \dz?
Thanks for your suggestion!
I'll replace it if I got consensus. :-D
How about using \dX rather than \dz?
Thanks for your suggestion!
I'll replace it if I got consensus. :-D
I re-read a help message of \d* commands and realized
Hi!
+1 good idea
+1 that's a good idea. Please add it to the next commitfest!
Thanks!
You have a typo:
+if (pset.sversion < 1)
+{
+charsverbuf[32];
+
+pg_log_error("The server (version %s) does not support
extended statistics.",
+
On Mon, Aug 24, 2020 at 6:13 AM Pavel Stehule wrote:
>
> po 24. 8. 2020 v 5:23 odesílatel Tatsuro Yamada
> napsal:
>>
>> Hi!
>>
>> I created a POC patch that allows showing a list of extended statistics by
>> "\dz" command on psql. I believe this feature helps DBA and users who
>> would like to
po 24. 8. 2020 v 5:23 odesílatel Tatsuro Yamada <
tatsuro.yamada...@nttcom.co.jp> napsal:
> Hi!
>
> I created a POC patch that allows showing a list of extended statistics by
> "\dz" command on psql. I believe this feature helps DBA and users who
> would like to know all extended statistics
Hi!
I created a POC patch that allows showing a list of extended statistics by
"\dz" command on psql. I believe this feature helps DBA and users who
would like to know all extended statistics easily. :-D
I have not a strong opinion to assign "\dz". I prefer "\dx" or "\de*"
than "\dz" but they
81 matches
Mail list logo
