On Mon, Jan 27, 2020 at 4:18 PM Tom Lane wrote:
> Robert Haas writes:
> >>> I do not think that the readability-vs-usefulness tradeoff is going
> >>> to be all that good there, anyway. Certainly for testing purposes
> >>> it's going to be more useful to examine portions of a structured output.
>
On Mon, Jan 27, 2020 at 11:01 AM Robert Haas wrote:
> On Fri, Nov 15, 2019 at 8:05 PM Maciek Sakrejda wrote:
> > On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> > > Personally, I don't care very much about backward-compatibility, or
> > > about how hard it is for tools to parse. I want it t
Robert Haas writes:
>>> I do not think that the readability-vs-usefulness tradeoff is going
>>> to be all that good there, anyway. Certainly for testing purposes
>>> it's going to be more useful to examine portions of a structured output.
> I intensely dislike having information that we can't sh
On Mon, Jan 27, 2020 at 12:41 PM Andres Freund wrote:
> > I do not think that the readability-vs-usefulness tradeoff is going
> > to be all that good there, anyway. Certainly for testing purposes
> > it's going to be more useful to examine portions of a structured output.
>
> I think I can live w
On Fri, Nov 15, 2019 at 8:05 PM Maciek Sakrejda wrote:
> On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> > Personally, I don't care very much about backward-compatibility, or
> > about how hard it is for tools to parse. I want it to be possible, but
> > if it takes a little extra effort, so
Hi,
On 2020-01-27 12:15:53 -0500, Tom Lane wrote:
> Maciek Sakrejda writes:
> > On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> >> Personally, I don't care very much about backward-compatibility, or
> >> about how hard it is for tools to parse. I want it to be possible, but
> >> if it takes
Maciek Sakrejda writes:
> On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
>> Personally, I don't care very much about backward-compatibility, or
>> about how hard it is for tools to parse. I want it to be possible, but
>> if it takes a little extra effort, so be it.
> I think these are two se
On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> Personally, I don't care very much about backward-compatibility, or
> about how hard it is for tools to parse. I want it to be possible, but
> if it takes a little extra effort, so be it.
I think these are two separate issues. I agree on
backwa
On Wed, Nov 13, 2019 at 3:03 PM Andres Freund wrote:
> Well, it's not been that way since the format option was added, so ...
It was pretty close in the original version, but people keep trying to
be clever.
> > I also think that conditionally renaming "Output" to "Project" is a
> > super-bad id
Hi,
On 2019-11-13 14:29:07 -0500, Robert Haas wrote:
> On Mon, Oct 28, 2019 at 7:21 PM Andres Freund wrote:
> > Because that's the normal way to represent something non-existing for
> > formats like json? There's a lot of information we show always for !text
> > format, even if not really applica
On Mon, Oct 28, 2019 at 7:21 PM Andres Freund wrote:
> Because that's the normal way to represent something non-existing for
> formats like json? There's a lot of information we show always for !text
> format, even if not really applicable to the context (e.g. Triggers for
> select statements). I
Hi,
On 2019-11-12 13:42:10 -0800, Maciek Sakrejda wrote:
> On Mon, Oct 28, 2019 at 5:02 PM Andres Freund wrote:
> > What I dislike about that is that it basically again is introducing
>
> "again"? Am I missing some history here? I'd love to read up on this
> if there are mistakes to learn from.
On Mon, Oct 28, 2019 at 5:02 PM Andres Freund wrote:
> What I dislike about that is that it basically again is introducing
"again"? Am I missing some history here? I'd love to read up on this
if there are mistakes to learn from.
> something that requires either pattern matching on key names (i.e
Hi,
On 2019-10-28 15:05:01 -0400, Robert Haas wrote:
> On Fri, Sep 27, 2019 at 3:21 AM Andres Freund wrote:
> > - JIT-Expr: whether the expression was JIT compiled (might e.g. not be
> > the case because no parent was provided)
> > - JIT-Deform-{Scan,Outer,Inner}: wether necessary, and whether
On Fri, Sep 27, 2019 at 3:21 AM Andres Freund wrote:
> - JIT-Expr: whether the expression was JIT compiled (might e.g. not be
> the case because no parent was provided)
> - JIT-Deform-{Scan,Outer,Inner}: wether necessary, and whether JIT
> accelerated.
>
> I don't like these names much, but ...
>But that's pretty crappy, because it means that the 'shape' of the output
>depends on the jit_details option.
Yeah, that would be hard to work with. What about adding it as a sibling group?
"Filter": "(lineitem.l_shipdate <= '1998-09-18 00:00:00'::timestamp
without time zone)",
"Filter JIT": {
Hi,
On 2019-09-27 00:20:53 -0700, Andres Freund wrote:
> Unfortunately I found a performance regression for JITed query
> compilation introduced in 12, compared to 11. Fixed in one of the
> attached patches
> (v1-0009-Fix-determination-when-tuple-deforming-can-be-JIT.patch
> - which needs a bette
17 matches
Mail list logo
