On Sat, Oct 17, 2009 at 10:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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 calculator
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
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
On Sun, Oct 18, 2009 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
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 set
On Sun, Oct 18, 2009 at 3:38 PM, Simon Riggs si...@2ndquadrant.com 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
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 1:25 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Sun, Oct 18, 2009 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Simon Riggs si...@2ndquadrant.com 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
On Sun, Oct 18, 2009 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
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
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, which
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 the user
Robert Haas wrote:
On Sat, Oct 17, 2009 at 9:53 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
21 matches
Mail list logo
