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 frontend-safe,
Christoph Berg c...@df7cb.de 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
... 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
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 and...@2ndquadrant.com 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
Andreas Karlsson andr...@proxel.se 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
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
is a
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
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
Andres Freund and...@2ndquadrant.com 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.
* 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 and...@2ndquadrant.com 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
On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Stephen Frost sfr...@snowman.net 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:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
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 be
Andres Freund and...@2ndquadrant.com 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
On 2014-04-27 17:49:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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,
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 be a
20 matches
Mail list logo
