On Mon, Apr 06, 2020 at 09:18:47PM -0700, Noah Misch wrote:
> On Mon, Apr 06, 2020 at 02:46:09PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Wed, Mar 25, 2020 at 04:42:31PM -0400, Tom Lane wrote:
> > >> So I think what we're actually trying to accomplish here is to
> > >> ensure that in
On 2020/05/25 15:24, Michael Paquier wrote:
On Mon, May 25, 2020 at 03:12:57PM +0900, Fujii Masao wrote:
Thanks! LGTM. Will commit this.
Oops :)
No problem :) Thanks for the commit!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DA
On 2020/05/25 16:03, Fujii Masao wrote:
On 2020/05/25 15:24, Michael Paquier wrote:
On Mon, May 25, 2020 at 03:12:57PM +0900, Fujii Masao wrote:
Thanks! LGTM. Will commit this.
Oops :)
No problem :) Thanks for the commit!
Thanks both!
Regards
Ian Barwick
--
Ian Barwick
> On Mon, May 25, 2020 at 06:34:30AM +1200, David Rowley wrote:
>
> > For a simple distinct query those UniqueKeys would be set based on
> > distinct clause. If I understand correctly, the very same is implemented
> > right now in create_distinct_paths, just after building all index paths,
> > so w
On Fri, 22 May 2020 at 12:12, Andy Fan wrote:
> Actually I am not sure about what does the "parameterized sub plan" mean (I
> treat is a SubPlan Node), so please correct me if I misunderstand you:)
> Because
> the inner plan in nest loop not a SubPlan node actually. so if bind the
> facility to
Spotted this in the release notes:
Add extension bool_plperl which transforms
SQL booleans to/from PL/Perl booleans (Ivan
Panchenko) WHERE IS THIS DOCUMENTED?
bool_plperl is documented in "44.1. PL/Perl Functions and Arguments", but not
with a separate section
On 15.02.2020 1:18, Tom Lane wrote:
The idea that 13 is unlucky is Western, and maybe even only common in
English-speaking countries.
Number 13 (especially Friday 13) is also considered unlucky In Czech
republic (central Europe, Slavic language).
--
Jiří.
On Fri, May 22, 2020 at 07:32:57PM -0400, Alvaro Herrera wrote:
> I don't know, but this stuff is so unused that your patch seems
> excessive ... and I think we'd rather not backpatch something so large.
> I propose we do something less invasive in the backbranches, like just
> throw elog() errors
On 2020-05-22 23:23, Jonathan S. Katz wrote:
Yeah. But there's still something to Jonathan's argument, because 9.6
will go EOL in November 2021, which is pretty close to when v14 will
reach public release (assuming we can hold to the typical schedule).
If we do it in v13, there'll be a full year
On 2020-05-22 18:53, Mark Dilger wrote:
I like the general direction you are going with this, but the decision in
v1-0006 to move the error for invalid object types out of gram.y and into
extension.c raises an organizational question. At some places in gram.y,
there is C code that checks par
On Mon, May 25, 2020 at 04:10:45AM +0200, Tomas Vondra wrote:
...
parallel queries
And now the fun begins ...
1) small one (SSD, max_parallel_workers_per_gather = 2)
algorithm master tlist prealloc prealloc+tlist
--
Em seg., 25 de mai. de 2020 às 03:57, Michael Paquier
escreveu:
> On Sun, May 24, 2020 at 02:50:08PM -0300, Ranier Vilela wrote:
> > Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan
> escreveu:
> >> It looks like they're only running pgbench for 60 second runs in all
> >> configurations --
On 5/12/20 8:06 AM, Joe Conway wrote:
> I was doing some memory testing under fractional CPU allocations and it became
> painfully obvious that the repeat() function needs CHECK_FOR_INTERRUPTS().
>
> I exchanged a few emails offlist with Tom about it, and (at the risk of
> putting
> words in his
On 2019-12-02 23:52, Thomas Munro wrote:
I'm not an expert in floating point math but hopefully it means that no
type change is required - double precision can handle it.
Me neither, but the SQL standard requires us to use an exact numeric
type, so it's wrong on that level by definition.
I loo
Peter Eisentraut writes:
> One problem (other than perhaps performance, tbd.) is that this would no
> longer allow processing infinite timestamps, since numeric does not
> support infinity. It could be argued that running extract() on infinite
> timestamps isn't very useful, but it's something
Joe Conway writes:
>> Comments or objections?
> Seeing none ... I intend to backpatch and push these two patches in the next
> day
> or so.
There was some question as to what (if anything) to do with the Windows
version of CHECK_FOR_INTERRUPTS. Have you resolved that?
On 5/25/20 9:52 AM, Tom Lane wrote:
> Joe Conway writes:
>>> Comments or objections?
>
>> Seeing none ... I intend to backpatch and push these two patches in the next
>> day
>> or so.
>
> There was some question as to what (if anything) to do with the Windows
> version of CHECK_FOR_INTERRUPTS.
On Fri, May 22, 2020 at 4:46 PM Amit Kapila wrote:
>
> On Fri, May 22, 2020 at 11:54 AM Amit Kapila wrote:
> >
> > v22-0006-Add-support-for-streaming-to-built-in-replicatio
> >
> >
> Few more comments on v22-0006 patch:
Joe Conway writes:
> On 5/25/20 9:52 AM, Tom Lane wrote:
>> There was some question as to what (if anything) to do with the Windows
>> version of CHECK_FOR_INTERRUPTS. Have you resolved that?
> Two questions.
> First, as I understand it, unlikely() is a gcc thing, so it does nothing at
> all
>
On 2020-05-25 16:37, Dilip Kumar wrote:
On Fri, May 22, 2020 at 11:54 AM Amit Kapila
wrote:
On Tue, May 19, 2020 at 6:01 PM Amit Kapila
wrote:
>
> On Fri, May 15, 2020 at 2:48 PM Dilip Kumar wrote:
> >
I have further reviewed v22 and below are my comments:
[v24.tar]
Hi,
I am not
On Mon, May 25, 2020 at 04:41:49PM +0300, Victor Yegorov wrote:
> New index to be created:
> CREATE INDEX i_mp_comments_mpath_gist ON comments.mp_comments USING gist
> (mpath);
I wonder if/how that fails if you create the index before adding data:
CREATE TABLE test_path(path ltree);
CREATE INDEX
On 5/25/20 5:45 AM, Peter Eisentraut wrote:
> On 2020-05-22 23:23, Jonathan S. Katz wrote:
>>> Yeah. But there's still something to Jonathan's argument, because 9.6
>>> will go EOL in November 2021, which is pretty close to when v14 will
>>> reach public release (assuming we can hold to the typica
On 5/25/20 3:28 PM, Peter Eisentraut wrote:
> On 2019-12-02 23:52, Thomas Munro wrote:
>>> I'm not an expert in floating point math but hopefully it means that no
>>> type change is required - double precision can handle it.
>> Me neither, but the SQL standard requires us to use an exact numeric
>>
Vik Fearing writes:
> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>> I looked into this (changing the return types of date_part()/extract()
>> from float8 to numeric).
> I think what would be better is to have a specific date_part function
> for each part and have extract translate to the appropr
On 5/25/20 6:40 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 5/25/20 3:28 PM, Peter Eisentraut wrote:
>>> I looked into this (changing the return types of date_part()/extract()
>>> from float8 to numeric).
>
>> I think what would be better is to have a specific date_part function
>> for each p
Vik Fearing writes:
> On 5/25/20 6:40 PM, Tom Lane wrote:
>> While at it, maybe we could
>> fix things so that the syntax reverse-lists the same way instead
>> of injecting Postgres-isms...
> I'm not sure what this means.
This:
regression=# create view myview as select extract(year from current
I wrote:
> What had been a 100% spec-compliant view definition is now quite
> Postgres-specific. I fixed some similar problems in 0bb51aa96 (before
> that, the CURRENT_TIMESTAMP part would've reverse-listed differently
> too); but I didn't tackle EXTRACT(), SUBSTRING(), and other cases.
> I'm not
Please don't take personal but when you open a discussion like that on number
13 then you are doing something very christian centric and forget the rest of
the world. As there are more cultural spheres than the christian one on this
planet can you please elaborate the next number which is acce
On Mon, 2020-05-25 at 04:10 +0200, Tomas Vondra wrote:
> algorithm master prealloc tlist prealloc-tlist
> --
> hash1365 437368 213
> sort 226 214224 215
>
> The sor
Updated patches are attached, I ditched the gmail web interface so
hopefully this works.
Not mentioned in Justin's feedback: I dropped the extra sort in the test
as it's no longer necessary. I also added a parallel dump -> parallel
restore -> dump test run for the directory format to get some free
> On May 25, 2020, at 2:55 AM, Peter Eisentraut
> wrote:
>
> On 2020-05-22 18:53, Mark Dilger wrote:
>> I like the general direction you are going with this, but the decision in
>> v1-0006 to move the error for invalid object types out of gram.y and into
>> extension.c raises an organizatio
Certificates I get at $work come four layers deep:
Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
Intermediate from "WE ISSUE TO LOTS OF FOLKS.COM"
Intermediate from "WE ISSUE TO ORGS LIKE YOURS.COM"
End-entity cert for my server.
Until today, we had the topmost, self-signe
On Mon, May 25, 2020 at 09:43:32AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > One problem (other than perhaps performance, tbd.) is that this would no
> > longer allow processing infinite timestamps, since numeric does not
> > support infinity. It could be argued that running extract
On 05/25/20 15:15, Chapman Flack wrote:
> Does that mean it also would fail if I directly put the server's
> end-entity cert there?
>
> Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS,
> WE ISSUE TO LOTS, and WE ISSUE TO EVERYBODY in the root.crt file
> in order for verification to su
On Mon, 2020-05-25 at 14:17 +0200, Tomas Vondra wrote:
> It's still ~2x slower than the sort, so presumably we'll need to
> tweak
> the costing somehow.
One thing to think about is that the default random_page_cost is only
4X seq_page_cost. We know that's complete fiction, but it's meant to
paper
On 2020-May-25, Michael Paquier wrote:
> I have been playing with the new APIs of xlogreader.h, and while
> merging some of my stuff with 13, I found the handling around
> ->seg.ws_file overcomplicated and confusing as it is necessary for a
> plugin to manipulate directly the fd of an opened segme
On Fri, Jun 28, 2019 at 10:06:28AM -0700, Noah Misch wrote:
> On Sun, Feb 17, 2019 at 11:31:03PM -0800, Noah Misch wrote:
> > I'm forking this thread from
> > https://postgr.es/m/flat/20190202083822.gc32...@gust.leadboat.com, which
> > reported a race condition involving the "apparent wraparound" s
On 2020-05-20 01:47, Tom Lane wrote:
I wrote:
However, we do have to have a benefit to show those people whose
queries we break. Hence my insistence on having a working AS fix
(or some other benefit) before not after.
I experimented with this a bit more, and came up with the attached.
It's not
The earlier patches weren't applying because I had "git config
diff.noprefix true" set globally and that was messing up the git
format-patch output.
On Mon, May 25, 2020 at 01:54:29PM -0500, David Gilman wrote:
> And I misunderstood how bad it was. I thought it was reading little
> header structs
On Mon, May 25, 2020 at 11:36:42AM -0700, Jeff Davis wrote:
On Mon, 2020-05-25 at 04:10 +0200, Tomas Vondra wrote:
algorithm master prealloc tlist prealloc-tlist
--
hash1365 437368 213
sor
Peter Eisentraut writes:
> What I was hoping to get out of this was to resolve some of the weird
> precedence hacks that were blamed on postfix operators.
Yeah, I was thinking about that too, but hadn't gotten to it.
> But building on your patch, the best I could achieve was
> -%nonassoc IDEN
On Mon, May 25, 2020 at 12:49:45PM -0700, Jeff Davis wrote:
On Mon, 2020-05-25 at 14:17 +0200, Tomas Vondra wrote:
It's still ~2x slower than the sort, so presumably we'll need to
tweak
the costing somehow.
One thing to think about is that the default random_page_cost is only
4X seq_page_cost.
I recently noticed this in a customer log file:
ERROR: could not read from hash-join temporary file: Success
The problem is we're reporting with %m when the problem is a partial
read or write.
I propose the attached patch to solve it: report "wrote only X of X
bytes". This caused a lot of oth
Alvaro Herrera writes:
> I recently noticed this in a customer log file:
> ERROR: could not read from hash-join temporary file: Success
> The problem is we're reporting with %m when the problem is a partial
> read or write.
> I propose the attached patch to solve it: report "wrote only X of X
>
On Mon, May 25, 2020 at 04:30:34PM -0400, Alvaro Herrera wrote:
> The original code did things as you suggest: the open_segment callback
> returned the FD, and the caller installed it in the struct. We then
> changed it in commit 850196b610d2 to have the CB install the FD in the
> struct directly.
I am reposting this from a few months back (see below). I am not trying to
be a pest, just very motivated. I really think this feature has merit, and
if not generally worthwhile, I'd be willing to pay someone to code it for
me as I don't have strong enough C skills to modify the PostgreSQL code
mys
Hello,
I think it is more useful if the name list of the
pg_shmem_allocations view is listed in one page.
For example,
* Wal Sender Ctl: walsender-related shared memory
* AutoVacuum Data: autovacuum-related shared memory
* PROCLOCK hash: shared memory for hash table for PROCLOCK structs
Why don
On Mon, May 25, 2020 at 07:53:40PM -0500, Bert Scalzo wrote:
> I am reposting this from a few months back (see below). I am not trying to be
> a
> pest, just very motivated. I really think this feature has merit, and if not
> generally worthwhile, I'd be willing to pay someone to code it for me as
On Sat, May 23, 2020 at 06:16:25PM +, Nikolay Samokhvalov wrote:
> This is a very good improvement! Using information about buffers is my
> favorite
> way to optimize queries.
>
> Not having BUFFERS enabled by default means that in most cases, when asking
> for
> help, people send execution
On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote:
> I think your best bet is to try getting someone to write a hook
> that will do the replacement so that you don't need to modify too much
> of the Postgres core code. You will need to have the hook updated for
> new versions of Postgr
On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote:
On Mon, May 25, 2020 at 07:53:40PM -0500, Bert Scalzo wrote:
I am reposting this from a few months back (see below). I am not trying to be a
pest, just very motivated. I really think this feature has merit, and if not
generally worth
On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> I am not excited about this new feature. Why do it only for EXPLAIN?
> That is a log of GUCs. I can see this becoming a feature creep
> disaster.
FWIW, Neither am I. This would create an extra maintenance cost, and
I would not wa
On Mon, May 25, 2020 at 10:54:03AM +0200, Daniel Gustafsson wrote:
> Spotted this in the release notes:
>
>
>Add extension bool_plperl which transforms
>SQL booleans to/from PL/Perl booleans (Ivan
>Panchenko) WHERE IS THIS DOCUMENTED?
>
>
> bool_plperl is doc
On Mon, May 25, 2020 at 11:05:09AM +0200, Jiří Fejfar wrote:
> On 15.02.2020 1:18, Tom Lane wrote:
> > The idea that 13 is unlucky is Western, and maybe even only common in
> > English-speaking countries.
>
> Number 13 (especially Friday 13) is also considered unlucky In Czech
> republic (central
Michael Paquier writes:
> On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote:
>> I think your best bet is to try getting someone to write a hook
>> that will do the replacement so that you don't need to modify too much
>> of the Postgres core code. You will need to have the hook update
On Mon, May 25, 2020 at 03:32:52PM -0400, Chapman Flack wrote:
> On 05/25/20 15:15, Chapman Flack wrote:
> > Does that mean it also would fail if I directly put the server's
> > end-entity cert there?
> >
> > Would I have to put all three of WE ISSUE TO ORGS LIKE YOURS,
> > WE ISSUE TO LOTS, and W
On Thu, 23 Apr 2020 at 12:55, Craig Ringer wrote:
> Patch 0001 fixes this issue with vpath postgres builds:
>
> $ make -C src/test/regress install-tests
> /usr/bin/install: cannot create regular file
> 'PGPREFIX/lib/postgresql/regress/PGPREFIX/src/test/regress/expected/errors.out':
> No such file
On Tue, May 26, 2020 at 10:16:19AM +0900, Masahiro Ikeda wrote:
> I think it is more useful if the name list of the
> pg_shmem_allocations view is listed in one page.
>
> Why don't you document pg_shmem_allocations view's name list?
Documenting that would create a dependency between the docs and
Rebased onto 7b48f1b490978a8abca61e9a9380f8de2a56f266 and renumbered OIDs.
>From bb41ae268041b7e7771930d533a8ca20a00805c7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Mon, 16 Mar 2020 14:12:55 -0500
Subject: [PATCH v18 01/10] Document historic behavior of links to
directories..
Backpatch t
On Fri, May 22, 2020 at 10:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Friday, May 22, 2020, Richard Guo wrote:
>
>> Hi hackers,
>>
>> For EXISTS SubLink, in some cases the subquery can be reduced to
>> constant TRUE or FALSE, based on the knowledge that it's being used in
>
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > I am not excited about this new feature. Why do it only for EXPLAIN?
Would probably help to understand what your thinking is here regarding
how it could be done for eve
On Thu, May 21, 2020 at 10:13:41AM -0400, David Steele wrote:
> +1. This schedule seems to have worked fine the last two years.
Sounds like a conclusion to me. I have created four new CFs for the
next development cycle then in the CF app.
--
Michael
signature.asc
Description: PGP signature
On Mon, May 25, 2020 at 6:36 PM, Bruce Momjian < br...@momjian.us > wrote:
>
>
>
> I am not excited about this new feature. Why do it only for EXPLAIN? That
> is a log of GUCs. I can see this becoming a feature creep disaster.
>
>
>
>
How about changing the default behavior, making BUFFERS
On Mon, May 25, 2020 at 06:29:10PM +0900, Michael Paquier wrote:
> Perhaps you are right though, and that we don't need to spend this
> much energy into improving the error messages so I am fine to discard
> this part. At the end, in order to remove the crashes, you just need
> to keep around the
On Tue, 2020-05-26 at 02:49 +, Nikolay Samokhvalov wrote:
> > I am not excited about this new feature. Why do it only for EXPLAIN? That
> > is a log of GUCs. I can see this becoming a feature creep disaster.
> >
>
> How about changing the default behavior, making BUFFERS enabled by default?
On 05/25/20 22:03, Bruce Momjian wrote:
> Did you review the PG documentation about intermediate certificates?
>
> https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CERTIFICATE-CREATION
AFAICT, there isn't much in that section to apply to my question.
> Is there a specific question you h
On Mon, 2020-05-25 at 15:15 -0400, Chapman Flack wrote:
> Certificates I get at $work come four layers deep:
>
>
> Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
>
> Intermediate from "WE ISSUE TO LOTS OF FOLKS.COM"
>
> Intermediate from "WE ISSUE TO ORGS LIKE YOURS.COM"
>
>
On Tue, May 26, 2020 at 05:22:13AM +0200, Laurenz Albe wrote:
> On Mon, 2020-05-25 at 15:15 -0400, Chapman Flack wrote:
> > Certificates I get at $work come four layers deep:
> >
> >
> > Self-signed CA cert from "WE ISSUE TO EVERYBODY.COM"
> >
> > Intermediate from "WE ISSUE TO LOTS OF FOLKS.C
On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote:
>
>FOR counter IN 1..180 LOOP
> id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0; id = 0; id = 0; id1 = 0;
> id2 = 0; id3 = 0; id1 = 0; id2 = 0;
> id3 = 0;
>END LOOP;
>
> This is no
On 05/25/20 23:22, Laurenz Albe wrote:
> I don't know if there is a way to get this to work, but the
> fundamental problem seems that you have got the system wrong.
>
> If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
> it as a certification authority.
That's a reasonable viewpoin
What about the SSH model? In the Postgres context, this would basically be
a table containing authorized certificates for each user. Upon receiving a
connection attempt, look up the user and the presented certificate and see
if it is one of the authorized ones. If so, do the usual verification that
On 2020-May-25, Chapman Flack wrote:
> If the libpq root.crt file can be made to work similarly to a
> Java trustStore, that expands the possible solution space.
If I understand you correctly, you want a file in which you drop any of
these intermediate CA's cert in, causing the server to trust a
On Tue, 26 May 2020 at 00:08, Alvaro Herrera
wrote:
> On 2020-May-25, Chapman Flack wrote:
>
> > If the libpq root.crt file can be made to work similarly to a
> > Java trustStore, that expands the possible solution space.
>
> If I understand you correctly, you want a file in which you drop any of
On 05/26/20 00:07, Alvaro Herrera wrote:
>> If the libpq root.crt file can be made to work similarly to a
>> Java trustStore, that expands the possible solution space.
>
> If I understand you correctly, you want a file in which you drop any of
> these intermediate CA's cert in, causing the server
On 05/26/20 00:07, Isaac Morland wrote:
> What about the SSH model? In the Postgres context, this would basically be
> a table containing authorized certificates for each user. Upon receiving a
> connection attempt, look up the user and the presented certificate and see
> if it is one of the author
On Fri, May 22, 2020 at 6:21 PM Dilip Kumar wrote:
>
> On Mon, May 18, 2020 at 5:57 PM Amit Kapila wrote:
> >
> >
> > Few comments on v20-0010-Bugfix-handling-of-incomplete-toast-tuple
> > 1.
> > + /*
> > + * If this is a toast insert then set the corresponding bit. Otherwise, if
> > + * we have
On Tue, May 26, 2020 at 10:59 AM Tomas Vondra
wrote:
> On Mon, May 25, 2020 at 12:49:45PM -0700, Jeff Davis wrote:
> >Do you think the difference in IO patterns is due to a difference in
> >handling reads vs. writes in the kernel? Or do you think that 128
> >blocks is not enough to amortize the co
On Tue, 26 May 2020 at 11:43, Chapman Flack wrote:
> On 05/25/20 23:22, Laurenz Albe wrote:
> > I don't know if there is a way to get this to work, but the
> > fundamental problem seems that you have got the system wrong.
> >
> > If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
>
Le mar. 26 mai 2020 à 04:27, Stephen Frost a écrit :
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > I am not excited about this new feature. Why do it only for EXPLAIN?
>
> Would probably help to understand
On Fri, May 22, 2020 at 6:22 PM Dilip Kumar wrote:
>
> On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote:
> >
> > On Sun, May 17, 2020 at 12:41 PM Dilip Kumar wrote:
> > >
> > > On Fri, May 15, 2020 at 4:04 PM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Review comments:
> > > > --
On Saturday, May 23, 2020, Vik Fearing wrote:
>
>
> > Do we really want default_explain_analyze ?
> > It sounds like bad news that EXPLAIN DELETE might or might not remove
> rows
> > depending on the state of a variable.
>
> I have had sessions where not using ANALYZE was the exception, not the
>
On Monday, May 25, 2020, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
> > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote:
> > > I am not excited about this new feature. Why do it only for EXPLAIN?
>
> Would probably help to understand what y
82 matches
Mail list logo
