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
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
... 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
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
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
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
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
>
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
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
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 (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
>
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
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
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
* 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
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
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
>>
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:
>> 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 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
20 matches
Mail list logo
