On Oct8, 2011, at 23:07 , Christopher Browne wrote:
> General purpose queries are nowhere near so predetermined. Indeed, whether a
> column is nullable may not be at all visible, as the value of a column may be
> computed by a function and thereby be quite opaque to static analysis.
I don't agr
Hanada-san,
The proposed patch put an invocation of PlanForeignJoin on the
create_foreignjoin_path() being also called by match_unsorted_outer().
Is it a suitable position to make a decision whether a join can be
pushed-down?
I think; it needs an additional functionality to provide higher priorit
Florian Pflug wrote:
> Coming up with a reasonable algorithm isn't *that* hard.
Agreed. Our shop has used a home-grown framework for over a decade
where we parse queries using ANTLR ( http://www.antlr.org/ ) and we
tracked this trough all expressions. There really weren't that many
situation
On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> Coming up with a reasonable algorithm isn't *that* hard.
>
> Agreed. Our shop has used a home-grown framework for over a decade
> where we parse queries using ANTLR ( http://www.antlr.org/ ) and we
> tracked this trough
On Oct9, 2011, at 13:35 , Kohei KaiGai wrote:
> I think; it needs an additional functionality to provide higher priority
> on the foreign-join plan that other plans, when fdw determind a particular
> join can be pushed-down.
> (Sorry, I have no idea right now.)
>
> Probably, the basic design is co
On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker wrote:
> If I find the time maybe Ill submit something along these lines for
> the next commit fest.
>
So i just picked up the non-inherited constraints patch and quickly
ran into the same problem and found this thread.
I think it makes sense to hold
"Kevin Grittner" writes:
> Florian Pflug wrote:
>> I don't think the reply to a DESCRIBE message is currently
>> extensible, so we'd probably need to add a new version of the
>> message.
> Or a new protocol version.
Exactly --- this *would* require a protocol version bump.
>> That might be a
Florian Pflug writes:
> On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
>> Yeah. It would be nice to see at least one use case. The only
>> comment I recall is a vague suggestion that that people might want to
>> select data from a table and infer table attributes from the result
>> set metadata
On 08.10.2011 21:51, Kevin Grittner wrote:
I tried to review the "Optimizing box_penalty" patch:
Thanks!
On the other hand, this patch leaves the code a few lines shorter and
eliminates some unnecessary Datum wrapping, PG_FUNCTION_ARGS
parameters on a static function, and allows that function
Jeff Davis writes:
> On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote:
>> When I apply this to head, "make check" fails with:
>>
>> create type textrange_en_us as range(subtype=text, collation="en_US");
>> + ERROR: collation "en_US" for encoding "SQL_ASCII" does not exist
> Thank you for poi
Marc Munro writes:
> It seems that in order to create an object in a given schema, I must
> have been granted create privilege on the schema. But in order to drop
> that object I require usage privilege.
> This means that with the right privilege settings I can create objects
> that I cannot s
On Oct9, 2011, at 17:56 , Tom Lane wrote:
> Florian Pflug writes:
>> On Oct9, 2011, at 14:20 , Kevin Grittner wrote:
>>> Yeah. It would be nice to see at least one use case. The only
>>> comment I recall is a vague suggestion that that people might want to
>>> select data from a table and infer
On Sun, Oct 9, 2011 at 09:17, Greg Stark wrote:
> On Fri, Oct 7, 2011 at 5:45 PM, Alex Hunsaker wrote:
>> If I find the time maybe Ill submit something along these lines for
>> the next commit fest.
>>
>
> So i just picked up the non-inherited constraints patch and quickly
> ran into the same pro
I created a patch corresponding FPW.
Fujii's patch (ver 9) is based.
Manage own FPW in shared-memory (on master)
* startup and walwriter process update it. startup initializes it
after REDO. walwriter updates it when started or received SIGHUP.
Insert WAL including a value of current F
On Sun, Oct 9, 2011 at 17:51, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Yeah, it wouldn't be hard to produce a long list of things which
>> would take about the same effort which seem more beneficial to me.
>> It's a matter of whether this is causing someone enough bother to
>> want to devote
2011/10/9 Jun Ishiduka :
> Insert WAL including a value of current FPW (on master)
> * In the the same timing as update, they insert WAL (is named
> XLOG_FPW_CHANGE). XLOG_FPW_CHANGE has a value of the changed FPW.
> * When it creates CHECKPOINT, it adds a value of current FPW to the
>
On Sun, 2011-10-09 at 11:58 -0400, Tom Lane wrote:
> Marc Munro writes:
> > It seems that in order to create an object in a given schema, I must
> > have been granted create privilege on the schema. But in order to drop
> > that object I require usage privilege.
>
> > This means that with the
On Tue, Sep 27, 2011 at 10:34 AM, Fujii Masao wrote:
> On Mon, Sep 26, 2011 at 7:45 PM, Peter Eisentraut wrote:
>> On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
>>> And it's not like we don't break configuration file
>>> contents in most releases anyway, so I really fail to see why this one
I wrote:
> I believe that we should rejigger things so that when an index-only scan
> is selected, the executor *always* works from the data supplied by the
> index. Even if it has to visit the heap --- it will do that but just to
> consult the tuple's visibility data, and then use what it got fro
On Sun, Oct 9, 2011 at 9:03 PM, Tom Lane wrote:
> At the moment I'm leaning to approach #3, but I wonder if anyone has
> a different opinion or another idea altogether.
>
Would any of these make it more realistic to talk about the crazy
plans Heikki suggested like doing two index scans, doing the
Greg Stark writes:
> On Sun, Oct 9, 2011 at 9:03 PM, Tom Lane wrote:
>> At the moment I'm leaning to approach #3, but I wonder if anyone has
>> a different opinion or another idea altogether.
> Would any of these make it more realistic to talk about the crazy
> plans Heikki suggested like doing
On Sun, Oct 9, 2011 at 10:54 PM, Tom Lane wrote:
> I don't think it's particularly relevant --- we would not want to use
> weird representations of the Vars outside the index scan nodes. Above
> the scan they'd be just like any other upper-level Vars.
I can't say I fully understand the planner d
I wrote:
> There are at least four things we could do: ...
> 2. Set varno = OUTER (or maybe INNER). This is safe because there's no
> other use for OUTER/INNER in a table scan node. We would have to hack
> things so that the index tuple gets put into econtext->ecxt_outertuple
> (resp. ecxt_innert
On Mon, Oct 10, 2011 at 2:47 AM, Tom Lane wrote:
> The need for this additional node list field also sways me in a
> direction that I'd previously been on the fence about, namely that
> I think index-only scans need to be their own independent plan node type
> instead of sharing a node type with r
[ Thanks all for the very productive discussion in the thread
"libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable"
which I originated. Very useful. Now on something different. ]
About two years ago, I had to research some PostgreSQL failures on
HP-UX on a lame PA-RISC box. Lookin
Alex Goncharov writes:
> About two years ago, I had to research some PostgreSQL failures on
> HP-UX on a lame PA-RISC box. Looking at the PostgreSQL source code
> then, I got an impression that running PostgreSQL on HP-UX was an open
> question -- HP-UX didn't seem like a seriously targeted platf
Thanks...
,--- You/Tom (Sun, 09 Oct 2011 22:29:19 -0400) *
| Well, HP hasn't exactly been forthcoming with support on their own end,
| but we do have an HPUX 11.31 IA64 machine in the buildfarm,
Should I read the above as:
1. The PostgreSQL server will build on HPUX 11.31 IA64.
2. The s
On Sun, Oct 9, 2011 at 1:56 PM, Alex Hunsaker wrote:
>> So i just picked up the non-inherited constraints patch and quickly
>> ran into the same problem and found this thread.
>>
>> I think it makes sense to hold off on this patch until these issues
>> are resolved. Because we really do need to te
On Sat, Oct 8, 2011 at 12:30 PM, Tom Lane wrote:
> Josh writes:
>> [ unhappy about users being able to freely adjust work_mem etc ]
>
> Really, if you're letting users issue arbitrary SQL queries, there
> simply isn't any way to prevent them from beating your server into
> the ground. I don't th
Robert Haas writes:
> On Sat, Oct 8, 2011 at 12:30 PM, Tom Lane wrote:
>> The reason that the specific variables you mention (as well as some
>> others that bear on such things) are USERSET and not SUSET is precisely
>> that we are not trying to constrain the amount of resources an
>> uncooperati
Hello
there is fix a locale dependency of regress tests
Last time I forgot to attach a patch
Regards
Pavel Stehule
*** ./src/test/regress/expected/foreign_data.out.orig 2011-10-04 13:56:41.0 +0200
--- ./src/test/regress/expected/foreign_data.out 2011-10-06 14:06:20.0 +0200
31 matches
Mail list logo
