mariem wrote:
> Hello,
>
> I would like to transform the query plan (output of the planner,
> debug_print_plan) into an sql query.
I don't think SQL can express the information the plan contains. For example,
join methods (hash, nest loop, merge).
--
Antonin Houska
Cybertec Schönig & Schönig
On Tue, Nov 4, 2014 at 10:03 PM, Heikki Linnakangas
wrote:
>
> On 10/30/2014 06:02 PM, Andres Freund wrote:
>>
>> On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote:
>>>
>>> On 10/06/2014 02:29 PM, Andres Freund wrote:
On 2014-10-06 14:19:39 +0300, Heikki Linnakangas wrote:
>
>>>
On Wed, Oct 22, 2014 at 11:32:41AM -0400, Tom Lane wrote:
> I don't have a strong opinion about which of the above things to do ...
> what's your preference?
I think it's better for the future if me make a clean cut. Yes, the option
keeps compatability a little bit higher, but that doesn't matter
On 11/3/14, 2:36 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical replication,
commit timestamp is not enough for conflict handling, you also need to have
additional info in order to identify
On Tue, Nov 04, 2014 at 08:30:21AM +, Laurenz Albe wrote:
> David Fetter wrote:
> > On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
> >> Just out of curiosity, why is Oracle's NUMBER (I assume you are
> >> talking about this) so fast?
> >
> > I suspect that what happens is that N
May be you want to check how it's done in Postgres-XC. Postgres-XC works on
plans being created by PostgreSQL and "reverse-engineers" queries (for
parts of the plans which are "shippable".) The notions of "shippability"
may not be of interest to you, but the code to "reverse-engineer" most of
the p
On Wed, Nov 5, 2014 at 6:29 AM, Peter Eisentraut wrote:
> On 11/4/14 3:21 PM, Alvaro Herrera wrote:
> > FWIW I gave this a trial run and found I needed some tweaks to test.sh
> > and the Makefile in order to make it work on VPATH; mainly replace ./
> > with `dirname $0` in a couple test.sh in a c
Thanks for the tests.
On Wed, Nov 5, 2014 at 5:21 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
> > On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
> > wrote:
> > > Although I doubt necessity of the flexibility seeing the current
> > > testing framework, I don't have so strong objection
On Fri, Oct 31, 2014 at 11:27 AM, Michael Paquier wrote:
> So, what I think is missing is really a friendly interface to manipulate
> JsonbContainers directly, and I think that we are not far from it with
> something like this set, roughly:
> - Initialization of an empty container
> - Set of APIs
Hello,
I would like to transform the query plan (output of the planner,
debug_print_plan) into an sql query.
I know that there are pieces of the query plan that might be machine
dependent (in var for example).
So I wanted to have your suggestions or thoughts before I put efforts into
it.
Basicall
Michael Paquier writes:
> MemSet is an internal macro faster than the system memset for zeroing small
> word-aligned structures defined in src/include/c.h. Both are being used
> here and there with no real preference.
> An example of that is that in many code paths we have for example nulls and
>
Hi all,
MemSet is an internal macro faster than the system memset for zeroing small
word-aligned structures defined in src/include/c.h. Both are being used
here and there with no real preference.
An example of that is that in many code paths we have for example nulls and
values used to build tuple
On 2014-11-05 08:57:07 +0900, Michael Paquier wrote:
> On Tue, Nov 4, 2014 at 10:01 PM, Alvaro Herrera
> wrote:
>
> > Michael Paquier wrote:
> >
> > > I'm still on a -1 for that. You mentioned that there is perhaps no reason
> > > to delay a decision on this matter, but IMO there is no reason to
On 04/11/14 09:07, Craig Ringer wrote:
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
Thank you for your comment, Tom. However I think this behavior, as
seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so
On 11/5/14, 12:59 AM, Tom Lane wrote:
Marko Tiikkaja writes:
So I got into thinking whether it would make sense to provide a new
function, say, to_char_at_timezone() to solve this problem. For example:
...
Any thoughts? The patch is quite trivial.
I'm not convinced that it's all that trivia
Marko Tiikkaja writes:
> So I got into thinking whether it would make sense to provide a new
> function, say, to_char_at_timezone() to solve this problem. For example:
> ...
> Any thoughts? The patch is quite trivial.
I'm not convinced that it's all that trivial. Is the input timestamp or
tim
On Tue, Nov 4, 2014 at 10:01 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
> > I'm still on a -1 for that. You mentioned that there is perhaps no reason
> > to delay a decision on this matter, but IMO there is no reason to rush
> > either in doing something we may regret. And I am not the
Hi,
9.4 FINALLY added the UTC offset formatting pattern to to_char().
However, it falls a bit short in the sense that it's always the time
zone offset according to the effective TimeZone value. This has a few
issues as far as I can tell:
1) It's not truly controlled by the query which pro
I wrote:
> An alternative that just occurred to me is to put the no-volatile-
> I/O-functions check into CREATE TYPE, but make it just WARNING not
> ERROR. That would be nearly as good as an ERROR in terms of nudging
> people who'd accidentally omitted a volatility marking from their
> custom type
--On 4. November 2014 17:18:14 -0500 Tom Lane wrote:
Yeah, and I think that it's entirely reasonable for rewriting ALTER TABLEs
to update the xmin of the rewritten tuples; after all, the output data
could be arbitrarily different from what the previous transactions put
into the table. But th
Andres Freund writes:
> On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
>> Not sure. The OP's point is that in a SELECT, you do get unsurprising
>> results, because a SELECT will acquire its execution snapshot after it's
>> gotten AccessShareLock on the table. Arguably COPY should behave likewise.
On 11/2/14 8:26 AM, Magnus Hagander wrote:
> The idea is to have pg_receivexlog
> fire off an external command at the end of each segment - for example
> a command to gzip the file, or to archive it off into a Magic Cloud
> (TM) or something like that.
A simple facility to allow gzipping after the
On 04/11/14 22:20, Peter Eisentraut wrote:
On 11/3/14 5:17 PM, Petr Jelinek wrote:
Please don't name anything "committs". That looks like a misspelling of
something.
There is nothing wrong with
pg_get_transaction_commit_timestamp()
If you want to reduce the length, lose the "get".
I am fi
On 11/4/14 3:21 PM, Alvaro Herrera wrote:
> FWIW I gave this a trial run and found I needed some tweaks to test.sh
> and the Makefile in order to make it work on VPATH; mainly replace ./
> with `dirname $0` in a couple test.sh in a couple of places, and
> something similar in the Makefile. Also yo
On 04/11/14 09:25, Michael Paquier wrote:
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund mailto:and...@2ndquadrant.com>> wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
> Well, Michael has point that the extradata is pretty much useless
currently,
> perhaps it would help to
On 11/3/14 5:17 PM, Petr Jelinek wrote:
>> Please don't name anything "committs". That looks like a misspelling of
>> something.
>>
>> There is nothing wrong with
>>
>> pg_get_transaction_commit_timestamp()
>>
>> If you want to reduce the length, lose the "get".
>>
>
> I am fine with that, I only
On 04/11/14 09:19, Michael Paquier wrote:
On Sat, Nov 1, 2014 at 10:00 PM, Michael Paquier
mailto:michael.paqu...@gmail.com>> wrote:
More comments:
Here are also more comments about the code that I found while focusing
on committs.c:
1) When the GUC is not enabled, and when the transaction
Michael Paquier wrote:
> On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
> wrote:
> > Although I doubt necessity of the flexibility seeing the current
> > testing framework, I don't have so strong objection about
> > that. Nevertheless, perhaps you are appreciated to put a notice
> > on.. READM
On 04/11/14 09:05, Andres Freund wrote:
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
Well, Michael has point that the extradata is pretty much useless currently,
perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But sure,
On 04/11/14 13:11, Heikki Linnakangas wrote:
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really works. Th
On 10/20/14 4:51 PM, Peter Eisentraut wrote:
> On 10/20/14 2:59 PM, Tom Lane wrote:
>> What do we want to do about this? I think a minimum expectation would be
>> for pg_basebackup to notice and complain when it's trying to create an
>> unworkably long symlink entry, but it would be far better if
Kevin Wooten wrote:
> > On Nov 4, 2014, at 12:55 AM, Craig Ringer wrote:
> >
> > I have to say I like some aspects of how pgjdbc-ng is being done - in
> > particular use of Maven and being built around non-blocking I/O.
> >
> > OTOH, the use of Google Guava I find pretty inexplicable in a JDBC
>
Michael Paquier wrote:
> On Mon, Jul 14, 2014 at 6:14 PM, Kyotaro HORIGUCHI
> wrote:
> > Although I doubt necessity of the flexibility seeing the current
> > testing framework, I don't have so strong objection about
> > that. Nevertheless, perhaps you are appreciated to put a notice
> > on.. READM
On 2014-11-04 13:51:23 -0500, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 3. November 2014 18:15:04 +0100 Sven Wegener
> > wrote:
> >> I've check git master and 9.x and all show the same behaviour. I came up
> >> with the patch below, which is against curent git master. The patch
> >> modifi
Thanks for looking at this patch.
> I suggest moving the rest of the changes into separate patches.
>
Hmmm... perhaps the following?
* superuser-cleanup - contains above mentioned superuser shortcuts only.
* has_privilege-cleanup - contains has_*_priviledge cleanup only.
Would that also requir
On 11/04/2014 07:33 AM, Tom Lane wrote:
> More generally, it seems like a grab bag of not terribly well designed
> features, and the features that do seem well designed seem like they
> ought to be more generic than just for int4 arrays. So to me it feels
> like proof-of-concept experimentation ra
On Tue, 4 Nov 2014, Tom Lane wrote:
> Bernd Helmle writes:
> > --On 3. November 2014 18:15:04 +0100 Sven Wegener
> > wrote:
> >> I've check git master and 9.x and all show the same behaviour. I came up
> >> with the patch below, which is against curent git master. The patch
> >> modifies the CO
On Tue, 4 Nov 2014, Bernd Helmle wrote:
> --On 3. November 2014 18:15:04 +0100 Sven Wegener
> wrote:
>
> > I've check git master and 9.x and all show the same behaviour. I came up
> > with the patch below, which is against curent git master. The patch
> > modifies the COPY TO code to create a ne
On 11/04/2014 01:51 PM, Tom Lane wrote:
Bernd Helmle writes:
--On 3. November 2014 18:15:04 +0100 Sven Wegener
wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git master. The patch
modifies the COPY TO code to crea
Bernd Helmle writes:
> --On 3. November 2014 18:15:04 +0100 Sven Wegener
> wrote:
>> I've check git master and 9.x and all show the same behaviour. I came up
>> with the patch below, which is against curent git master. The patch
>> modifies the COPY TO code to create a new snapshot, after acquir
Andrew Dunstan writes:
>> here's a patch for a utility function to look up the cast function for
>> a from/to pair of types, as recently suggested by Alvaro. Although it
>> only contains one use (in json.c), the upcoming jsonb generators would
>> also use it twice. I'd like to get this committe
--On 3. November 2014 18:15:04 +0100 Sven Wegener
wrote:
I've check git master and 9.x and all show the same behaviour. I came up
with the patch below, which is against curent git master. The patch
modifies the COPY TO code to create a new snapshot, after acquiring the
necessary locks on th
On 11/04/2014 12:57 PM, Andrew Dunstan wrote:
here's a patch for a utility function to look up the cast function for
a from/to pair of types, as recently suggested by Alvaro. Although it
only contains one use (in json.c), the upcoming jsonb generators would
also use it twice. I'd like to get
missing patch
Regards
Pavel
2014-11-04 18:57 GMT+01:00 Andrew Dunstan :
>
> here's a patch for a utility function to look up the cast function for a
> from/to pair of types, as recently suggested by Alvaro. Although it only
> contains one use (in json.c), the upcoming jsonb generators would als
here's a patch for a utility function to look up the cast function for a
from/to pair of types, as recently suggested by Alvaro. Although it only
contains one use (in json.c), the upcoming jsonb generators would also
use it twice. I'd like to get this committed fairly quickly so I can
prepare
On 10/27/14 11:40 AM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>>> As I started looking at this, there are multiple other places where
>>> these types of error messages occur (opclasscmds.c, user.c,
>>> postinit.c, miscinit.c are just a few), not just around the cha
Peter Eisentraut writes:
> On 10/9/14 1:58 PM, Fujii Masao wrote:
>> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
>> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
>> about applying the attached patch? This patch allows that and
>> changes the context of session_prelo
I wrote:
> However: at no point in this sequence did we flush the original catalog
> blocks out of shared buffers. Therefore, a read of the database's
> pg_class or pg_type at this point is likely to find the previous states of
> those pages (pre-composite-type-drop) as valid, matching entries, so
> On Nov 4, 2014, at 12:55 AM, Craig Ringer wrote:
>
> On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
>> I also think the async I/O is the way to go. Luckily that has already been
>> done
>> in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
>> of netty java NIO library. It
On 10/9/14 1:58 PM, Fujii Masao wrote:
> Also I think that it's useful to allow ALTER ROLE/DATABASE SET to
> set PGC_BACKEND and PGC_SU_BACKEND parameters. So, what
> about applying the attached patch? This patch allows that and
> changes the context of session_preload_libraries to PGC_SU_BACKEND.
On Mon, 2014-11-03 at 22:08 -0500, Tom Lane wrote:
> Fascinating.
:-)
> I believe what is happening is:
[ . . . ]
> > This is not mission-critical for me but I'd be grateful for suggestions for
> > work-arounds.
>
> I don't see any workaround that's much easier than fixing the bug.
> But what'
Craig Ringer writes:
> On 11/03/2014 03:41 AM, Tom Lane wrote:
>> Nothing that I recall at the moment, but there is certainly plenty of
>> stuff of dubious quality in there. I'd argue that chkpass, intagg,
>> intarray, isn, spi, and xml2 are all in worse shape than the money type.
> What's wrong
On Tue, Oct 7, 2014 at 10:33 PM, Heikki Linnakangas
wrote:
>
> Some time ago, when debugging a GIN bug, I wrote these pageinspect
functions to inspect GIN indexes. They were very useful; we should add them.
>
I think these functions will be quite useful for debugging purpose
and we already have s
On 10/6/14 10:24 PM, Ali Akbar wrote:
> While reviewing the patch myself, i spotted some formatting problems in
> the code. Fixed in this v5 patch.
>
> Also, this patch uses context patch format (in first versions, because
> of the small modification, context patch format obfucates the changes.
>
On 7/8/14 6:03 AM, Ali Akbar wrote:
> If we put 1 as the parameter, the resulting Node will link to the
> existing children. In this case, the namespace problem for the children
> might be still exists. If any of the children uses different
> namespace(s) than the parent, the namespace definition w
On 7/11/14 4:36 AM, Ali Akbar wrote:
> But i found some bug in libxml2's code, because we call xmlCopyNode with
> 1 as the second parameter, internally xmlCopyNode will call
> xmlStaticCopyNode recursively via xmlStaticCopyNodeList. And
> xmlStaticCopyNodeList doesn't check the return of xmlStaticC
Tue, 4 Nov 2014 14:41:56 +0100 от Andres Freund :
> Hi,
>
> On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
> > * What the patch does in a short paragraph: This patch should add option
> > recovery_timeout, which help to control timeout of restore_command nonzero
> > status code. Right
On 11/03/2014 10:11 PM, Tom Lane wrote:
Josh Berkus writes:
On 11/02/2014 11:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all in worse shape tha
On Tue, Nov 4, 2014 at 8:16 AM, Kevin Grittner wrote:
> In any event, I'm against removing or re-deprecating the money
> type. There are some problems with money; there are other problems
> with numeric. If the docs are failing to make the trade-offs
> clear, we should fix the docs. And we can
On 11/02/2014 06:41 PM, Tom Lane wrote:
I wrote:
Either way, requiring a dump/reload for upgrade is surely a better answer
for users of the type than just summarily screwing them.
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you pr
Feng Tian wrote:
> Performance different between Money and Numeric is *HUGE*. For
> TPCH Q1, the performance difference is 5x for stock postgres, and
> ~20x for vitesse.
>
> Stock postgres, for my laptop, TPCH 1G, Q1, use money type ~ 9s,
> use Numeric (15, 2) is ~53s.
>
>> test=# do $$ begin pe
On Tue, Nov 04, 2014 at 11:44:22AM +0900, Michael Paquier wrote:
> On Sun, Nov 2, 2014 at 2:30 AM, Tom Lane wrote:
>
> > In the case of hash indexes, because we still have to have the hash
> > opclasses in core, there's no way that it could be pushed out as an
> > extension module even if we othe
Hi,
On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
> * What the patch does in a short paragraph: This patch should add option
> recovery_timeout, which help to control timeout of restore_command nonzero
> status code. Right now default value is 5 seconds. This is useful, if I using
> for
On 2014-11-04 08:21:13 -0500, Robert Haas wrote:
> On Tue, Nov 4, 2014 at 4:47 AM, Heikki Linnakangas
> wrote:
> > I hear none, so committed with some small fixes.
>
> Are you going to get the slice-by-N stuff working next, to speed this up?
I don't plan to do anything serious with it, but I've
On 2014-11-04 10:01:00 -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
>
> > I'm still on a -1 for that. You mentioned that there is perhaps no reason
> > to delay a decision on this matter, but IMO there is no reason to rush
> > either in doing something we may regret. And I am not the only
On Tue, Nov 4, 2014 at 4:47 AM, Heikki Linnakangas
wrote:
> I hear none, so committed with some small fixes.
Are you going to get the slice-by-N stuff working next, to speed this up?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-
On Mon, Nov 3, 2014 at 4:44 PM, Peter Eisentraut wrote:
> On 10/29/14 8:42 AM, Robert Haas wrote:
>> I'm sympathetic to that line of reasoning, but I really think that if
>> you want to keep this infrastructure, it needs to be made portable.
>
> Let me clarify that this was my intention. I have l
Michael Paquier wrote:
> I'm still on a -1 for that. You mentioned that there is perhaps no reason
> to delay a decision on this matter, but IMO there is no reason to rush
> either in doing something we may regret. And I am not the only one on this
> thread expressing concern about this extra data
On 10/13/2014 01:01 PM, Petr Jelinek wrote:
Hi,
I rewrote the patch with different API along the lines of what was
discussed.
Thanks, that's better.
It would be good to see an alternative seqam to implement this API, to
see how it really works. The "local" one is too dummy to expose any
pos
Mon, 3 Nov 2014 22:55:02 -0200 от Fabrízio de Royes Mello
:
>
>
>
> On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev < leopard...@inbox.ru > wrote:
> >
> >
> >
> >
> > Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello <
> > fabriziome...@gmail.com >:
> > >
> > > >
> > > > Should I ch
On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera
wrote:
>
> So here's v21. I also attach a partial diff from v20, just in case
> anyone wants to give it a look.
>
This needs a bump to 1.3, or the extension won't install:
contrib/pageinspect/pageinspect.control
During crash recovery, I am getti
On 10/27/2014 06:02 PM, Heikki Linnakangas wrote:
I came up with the attached patches. They do three things:
1. Get rid of the 64-bit CRC code. It's not used for anything, and
haven't been for years, so it doesn't seem worth spending any effort to
fix them.
2. Switch to CRC-32C (Castagnoli) for
On 2014-11-04 17:29:04 +0900, Michael Paquier wrote:
> On Tue, Nov 4, 2014 at 5:23 PM, Andres Freund
> wrote:
>
> > On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
> > > 5) Reading the code, TransactionTreeSetCommitTimestamp is always called
> > > with do_xlog = false, making that actually n
On 3 November 2014 22:18, Alvaro Herrera wrote:
> So here's v21. I also attach a partial diff from v20, just in case
> anyone wants to give it a look.
Looks really good.
I'd like to reword this sentence in the readme, since one of the main
use cases would be tables without btrees
It's unlik
David Fetter wrote:
> On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
>> Just out of curiosity, why is Oracle's NUMBER (I assume you are
>> talking about this) so fast?
>
> I suspect that what happens is that NUMBER is stored as a native type
> (int2, int4, int8, int16) that depends
On Tue, Nov 4, 2014 at 5:23 PM, Andres Freund
wrote:
> On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
> > 5) Reading the code, TransactionTreeSetCommitTimestamp is always called
> > with do_xlog = false, making that actually no timestamps are WAL'd...
> Hence
> > WriteSetTimestampXlogRec is
On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund
wrote:
> On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
> > Well, Michael has point that the extradata is pretty much useless
> currently,
> > perhaps it would help to add the interface to set extradata?
>
> Only accessible via C and useless aren't
On 2014-11-04 17:19:18 +0900, Michael Paquier wrote:
> 5) Reading the code, TransactionTreeSetCommitTimestamp is always called
> with do_xlog = false, making that actually no timestamps are WAL'd... Hence
> WriteSetTimestampXlogRec is just dead code with the latest version of the
> patch. IMO, this
On Sat, Nov 1, 2014 at 10:00 PM, Michael Paquier
wrote:
> More comments:
>
I have done a couple of tests on my laptop with pgbench like that to
generate a maximum of transaction commits:
$ pgbench --no-vacuum -f ~/Desktop/commit.sql -T 60 -c 24 -j 24
$ cat ~/Desktop/commit.sql
SELECT txid_curren
On 11/04/2014 07:31 AM, Álvaro Hernández Tortosa wrote:
> Thank you for your comment, Tom. However I think this behavior, as
> seen from a user perspective, it's not the expected one.
That may be the case, but I think it's the SQL-standard behaviour, so we
can't really mess with it.
The spec
On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
> Well, Michael has point that the extradata is pretty much useless currently,
> perhaps it would help to add the interface to set extradata?
Only accessible via C and useless aren't the same thing. But sure, add
it.
Greetings,
Andres Freund
--
81 matches
Mail list logo
