Andrew Chernow píše v ne 18. 10. 2009 v 21:09 -0400:
> > I'm curious if this is a lost hope. My boss is recommending we flatten
> > the Sun box and install redhat linux (which I'm fine with). I'd rather
> > not as threading in Solaris is better.
>
> Maybe solaris threads were better 10-15 year
u235sentinel píše v ne 18. 10. 2009 v 17:50 -0600:
> Are you sure about this? When I try to build and don't have openssl in
> the lib/include path it claims it needs it. As I'm building 64 bit I
> can now build postgres in 64 bit with openssl 98k just fine. However
> when I run it I'm getting
Actually i thought of a solution for the wrap-around sometime back. Let me
try to put my initial thoughts into it. May be it would get refined over
conversation.
Transaction wrap-around failure
Actually this problem is present even in today's transaction id scenario and
the only way we avoid is b
Robert Haas wrote:
> On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
> wrote:
>> This raises an important point: We need *developer documentation* on how
>> to write SE-Pgsql compliant permission checks. Not only for authors of
>> 3rd party modules but for developers of PostgreSQL itself. Poin
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> 1) creation of a database object
>>
>> In SELinux model, when a user tries to create a new object (not limited
>> to database object, like a file or socket), a default security context
>> is assigned on the new object, then SELinux checks whether t
On Thu, Sep 17, 2009 at 5:14 PM, I wrote:
> I think that the next project in this area should
> be to try to support removal of INNER joins. (Removal of SEMI, ANTI,
> and FULL joins seems unlikely ever to be interesting.) That will
> require teaching the planner about foreign key constraints, whi
I'm curious if this is a lost hope. My boss is recommending we flatten
the Sun box and install redhat linux (which I'm fine with). I'd rather
not as threading in Solaris is better.
Maybe solaris threads were better 10-15 years ago, but I'm not convinced that is
still the case. Any data supp
Are you sure about this? When I try to build and don't have openssl in
the lib/include path it claims it needs it. As I'm building 64 bit I
can now build postgres in 64 bit with openssl 98k just fine. However
when I run it I'm getting the same error message.
I'm curious if this is a lost ho
On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> If possible, I think we should try to engineer things so that using
>> pg_dump 8.5 on an 8.4 database and restoring the result into an 8.5
>> database produces a function with identical semantics.
>
> Hmm ... actually, we c
Simon Riggs writes:
> On Sun, 2009-10-18 at 14:50 -0400, Tom Lane wrote:
>> I'd like to suggest boosting the built-in cost estimates for the
>> xxx_has_privilege functions to perhaps 10. to_tsquery and to_tsvector
>> maybe should be boosted even higher, but I don't have a good specific
>> number
Robert Haas writes:
> If possible, I think we should try to engineer things so that using
> pg_dump 8.5 on an 8.4 database and restoring the result into an 8.5
> database produces a function with identical semantics.
Hmm ... actually, we could have pg_dump stick either a #option line
or a GUC SET
On Sun, Oct 18, 2009 at 3:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not? As Andrew pointed out, what we're really trying to
Robert Haas writes:
> You could probably convince me that a merge join is not going to be
> too useful (how often can you want a merge join on the inner side of a
> nested loop?
Why not? As Andrew pointed out, what we're really trying to accomplish
here is consider sub-join plans that are parame
On Sun, Oct 18, 2009 at 1:25 PM, Tom Lane wrote:
> As most of you will recall, plpgsql currently acts as though identifiers
> in SQL queries should be resolved first as plpgsql variable names, and
> only failing that do they get processed as names of the query. The
> plpgsql parser rewrite that I
On Sun, 2009-10-18 at 13:25 -0400, Tom Lane wrote:
> As most of you will recall, plpgsql currently acts as though identifiers
> in SQL queries should be resolved first as plpgsql variable names, and
> only failing that do they get processed as names of the query. The
> plpgsql parser rewrite that
On Sun, Oct 18, 2009 at 3:38 PM, Simon Riggs wrote:
> On Sun, 2009-10-18 at 14:50 -0400, Tom Lane wrote:
>
>> I'd like to suggest boosting the built-in cost estimates for the
>> xxx_has_privilege functions to perhaps 10. to_tsquery and to_tsvector
>> maybe should be boosted even higher, but I don
On Sun, 2009-10-18 at 14:50 -0400, Tom Lane wrote:
> I'd like to suggest boosting the built-in cost estimates for the
> xxx_has_privilege functions to perhaps 10. to_tsquery and to_tsvector
> maybe should be boosted even higher, but I don't have a good specific
> number in mind.
ISTM we should s
On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think you should only ever join an incomplete inner-indexscan path
>> to (1) another inner-indexscan path or (2) the cheapest total path for
>> *exactly* the future-join requirement. Anything else doesn't seem
>> produc
We recently saw a complaint about psql \d commands being quite slow
with many tables, which turned out to be because the planner was
putting a table_has_privilege() call where it would get executed a
lot, before other cheaper tests on pg_class. This is not the
planner's fault --- it has no informa
As most of you will recall, plpgsql currently acts as though identifiers
in SQL queries should be resolved first as plpgsql variable names, and
only failing that do they get processed as names of the query. The
plpgsql parser rewrite that I'm working on will fix that for the
obviously-silly cases
Bruce Momjian wrote:
> Yep, this is illustrating something that is pretty basic to open source
> --- that is open source often provides the tools for a solution, rather
> than a complete solution. I often think of open source as providing a
> calculator with wires sticking out, rather than calcula
Robert Haas writes:
> I think you should only ever join an incomplete inner-indexscan path
> to (1) another inner-indexscan path or (2) the cheapest total path for
> *exactly* the future-join requirement. Anything else doesn't seem
> productive.
I don't see any reason to constrain the form of jo
On Sat, Oct 17, 2009 at 10:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> That still leaves a lot of silly paths, though. In many cases, if
>> you're thinking about joining A to {B C} using an index-accelerated
>> path, you'd be just as well off joining to B first and then to C. So
>> it might
23 matches
Mail list logo
