On 27 April 2014 22:38, Tom Lane Wrote:
> ... and not, in particular, parse analysis or rewrite time?
>
> I'd been a bit suspicious of the recent patch to add $SUBJECT without
> the other pre-execution components, but it just now occurred to me that
> there's at least one reason why this might b
Andres Freund writes:
>> Just for some clarity, that also happens with expressions like:
>> WHERE
>> ROW(ev_class, rulename, ev_action) >= ROW('pg_rewrite'::regclass, '_RETURN',
>> NULL)
>> ORDER BY ROW(ev_class, rulename, ev_action);
> Previously we wouldn't detoast ev_action here, but now we d
On 2014-04-27 17:49:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
> >> Ah, I see. Well, we're pretty darn stupid about such queries anyway :-(.
> >> Your first example could be greatly improved by expanding the whole-row
> >> Var into a ROW()
Andres Freund writes:
> On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
>> Ah, I see. Well, we're pretty darn stupid about such queries anyway :-(.
>> Your first example could be greatly improved by expanding the whole-row
>> Var into a ROW() construct (so that RowCompareExpr could be used), and
>>
Tom,
> I'd been a bit suspicious of the recent patch to add $SUBJECT
> without the other pre-execution components, but it just now
> occurred to me that there's at least one reason why this might
> be a significant omission: any delay caused by waiting to acquire
> locks on the query's tables will
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I'd been a bit suspicious of the recent patch to add $SUBJECT
> >> without the other pre-execution components, but it just now
> >> occurred to me that there's at least one reason why thi
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd been a bit suspicious of the recent patch to add $SUBJECT
>> without the other pre-execution components, but it just now
>> occurred to me that there's at least one reason why this might
>> be a significant omission: any delay c
On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> >>> Meh ... is it likely that the columns involved in an ordering comparison
> >>> would be so wide as to be toasted out-of-line? Such a query would only be
> >>> fast if the
On 2014-04-27 16:55:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
> >> According to the commit message, the point of that was to allow
> >> pg_xlogdump to use relpath(), but I do not see it doing so;
>
> > Well, pg_xlogdump.c itself doesn't us
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'd been a bit suspicious of the recent patch to add $SUBJECT
> without the other pre-execution components, but it just now
> occurred to me that there's at least one reason why this might
> be a significant omission: any delay caused by waiting to acquire
>
Andres Freund writes:
> On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
>> According to the commit message, the point of that was to allow
>> pg_xlogdump to use relpath(), but I do not see it doing so;
> Well, pg_xlogdump.c itself doesn't use it, but some of the desc routines
> do. Like e.g. xact_d
Tom Lane-2 wrote
> Or we could add them into
> just the first planning-time printout, though that might also be
> misleading.
If you are going to show a number for these steps, which seems like a good
idea, then this seems like a reasonable option in the face of this
situation.
Basically two opti
Hi,
On 2014-04-27 16:33:29 -0400, Tom Lane wrote:
> > So it seems to me the right fix for the relpath end of it is to push most
> > of relpath.c back where it came from, which I think was backend/catalog/.
>
> In short, what I'm proposing here is to revert commit
> a73018392636ce832b09b5c31f6ad1f
I wrote:
> On closer inspection, the issue here is really that putting relpath.h/.c
> in common/ was completely misguided from the get-go. It's unnecessary:
> there's nothing outside the backend that uses it, except for
> contrib/pg_xlogdump which could very easily do without it. And relpath.h
>
Andreas Karlsson writes:
> On 04/27/2014 07:07 PM, Tom Lane wrote:
>> Rewrite timing could easily be captured by EXPLAIN since that call
>> is done within ExplainQuery(). Parse analysis isn't, but we could
>> imagine having transformExplainStmt() time the operation and stick
>> the result into a
Andres Freund writes:
>> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
>>> Meh ... is it likely that the columns involved in an ordering comparison
>>> would be so wide as to be toasted out-of-line? Such a query would only be
>>> fast if the row value were indexed, which would pretty much preclud
On 04/27/2014 07:07 PM, Tom Lane wrote:
Rewrite timing could easily be captured by EXPLAIN since that call
is done within ExplainQuery(). Parse analysis isn't, but we could
imagine having transformExplainStmt() time the operation and stick
the result into a new field in struct ExplainStmt.
I'm
... and not, in particular, parse analysis or rewrite time?
I'd been a bit suspicious of the recent patch to add $SUBJECT
without the other pre-execution components, but it just now
occurred to me that there's at least one reason why this might
be a significant omission: any delay caused by waitin
Christoph Berg writes:
> Re: Tom Lane 2014-04-26 <21449.1398524...@sss.pgh.pa.us>
>> Clearly, the idea that common/ is server-only is broken.
> The next step should probably be something like this:
Somebody who's spent more time than I have on the "make install" support
will have to comment on t
Re: Tom Lane 2014-04-26 <21449.1398524...@sss.pgh.pa.us>
> > internal/postgres_fe.h includes
> > common/fe_memutils.h which includes
> > utils/palloc.h
>
> Hm. It seems rather fundamentally broken to me that frontend code is
> including palloc.h --- that file was never intended to be fronte
20 matches
Mail list logo
