Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote:
It's my understanding that the philosophy of the PGDG in the past has
been to avoid putting any kind of hints into the system, focusing
rather an improving the planning of queries.
On Wed, 2008-06-25 at 23:34 -0400, Robert Haas wrote:
I can predict that Tom will say that the planning time it would take
to avoid this problem isn't justified by the number of queries that it
would improve.
That's possible, but it's unfortunate that there's no
way to fiddle with the
[EMAIL PROTECTED] (Simon Riggs) writes:
On Wed, 2008-06-25 at 23:34 -0400, Robert Haas wrote:
I can predict that Tom will say that the planning time it would take
to avoid this problem isn't justified by the number of queries that it
would improve.
That's possible, but it's unfortunate
IMHO we should have a single parameter which indicates how much planning
time we consider acceptable for this query. e.g.
optimization_level = 2 (default), varies 1-3
Most automatic optimisation systems allow this kind of setting, whether
it be a DBMS, or compilers (e.g. gcc).
It's my
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote:
IMHO we should have a single parameter which indicates how much planning
time we consider acceptable for this query. e.g.
optimization_level = 2 (default), varies 1-3
Most automatic optimisation systems allow this kind of setting,
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote:
It's my understanding that the philosophy of the PGDG in the past has
been to avoid putting any kind of hints into the system, focusing
rather an improving the planning of queries.
It's not a specific
On Thu, 2008-06-26 at 12:57 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote:
It's my understanding that the philosophy of the PGDG in the past has
been to avoid putting any kind of hints into the system, focusing
rather an
Simon Riggs wrote:
IMHO we should have a single parameter which indicates how much planning
time we consider acceptable for this query. e.g.
optimization_level = 2 (default), varies 1-3
Couldn't the planner itself make a good guess if it should
keep trying based on the estimated cost?
if
Ron Mayer [EMAIL PROTECTED] writes:
Couldn't the planner itself make a good guess if it should
keep trying based on the estimated cost?
if (the_best_plan_I_found_so_far_looks_like_itll_take_an_hour)
keep_optimizing_for_a_few_minutes
if
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Couldn't the planner itself make a good guess if it should
keep trying based on the estimated cost?
if (the_best_plan_I_found_so_far_looks_like_itll_take_an_hour)
keep_optimizing_for_a_few_minutes
if
Hi,
On Thursday 26 June 2008 04:36:09 Tom Lane wrote:
Andres Freund [EMAIL PROTECTED] writes:
SELECT *
FROM
ab LEFT OUTER JOIN (
bc JOIN cd
ON bc.c = cd.d
)
ON ab.b = bc.b
WHERE
ab.a = 2
As ab.a = 2 occurs only once in ab
Andres Freund [EMAIL PROTECTED] writes:
The only way it could do that would be by interchanging the order of the
left and inner joins, ie (ab left join bc) join cd; which would change
the results.
My knowledge about the implementation side of relational databases is quite
limited, so my
Andres Freund [EMAIL PROTECTED] writes:
SELECT *
FROM
ab LEFT OUTER JOIN (
bc JOIN cd
ON bc.c = cd.d
)
ON ab.b = bc.b
WHERE
ab.a = 2
As ab.a = 2 occurs only once in ab one would expect that it just does an
index scan
SELECT * FROM ab LEFT OUTER JOIN (bc JOIN cd ON bc.c = cd.d) ON ab.b = bc.b
WHERE ab.a = 2
As ab.a = 2 occurs only once in ab one would expect that it just does an
index scan on bc for ab.b = bc.b.
The only way it could do that would be by interchanging the order of the
left and
Robert Haas [EMAIL PROTECTED] writes:
I can predict that Tom will say that the planning time it would take
to avoid this problem isn't justified by the number of queries that it
would improve.
Took the words right out of my mouth ;-)
It would be *possible* to do this sort of thing, but what
15 matches
Mail list logo
