Hi
Could someone please try and explain why the cost estimator for the hash
is implemented as it is? (cost_hashjoin in costsize.c)
Especially these issues:
First, there is the estimation on the number of rows and their size.
ExecChooseHashTableSize() apparently trusts neither and doubles them.
Bruce Momjian wrote:
Our current WAL implementation writes copies of full pages to WAL before
modifying the page on disk. This is done to prevent partial pages from
being corrupted in case the operating system crashes during a page
write.
InnoDB uses a doublebuffer system instead.
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
Joining {b,c} to {a} does not meet any of those four allowed cases.
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?
We don't, because
Tom Lane wrote:
[SNIP: a repetion of my first post ;) ]
I think it should be
/*
* If we already joined IN's RHS to anything else in
* either input path, then this join is not constrained (the
* necessary work was done at a lower level).
Hi
I have a problem understanding the code to make certain in join are
performed properly. Specifically I have problems understading when
IN_UNIQUE_{INNER,OUTER} is a valid jointype.
Its in joinrels.c:make_join_rel.
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}.
No, it does
[EMAIL PROTECTED] wrote:
On 12 Feb, Tom Lane wrote:
http://developer.osdl.org/markw/dbt3-pgsql/62/
This run changes default_statistics_target to 1000 and I have p_partkey,
l_partkey, ps_suppkey, and l_suppkey pg_stats here at 1 min intervals
http (no links on the web page.) Pretty
You are refering to:
@inproceedings{ hellerstein93predicate,
author = Joseph M. Hellerstein and Michael Stonebraker,
title = Predicate migration: optimizing queries with expensive
predicates,
pages = 267--276,
year = 1993,
abstract = The traditional focus of relational query
Simon Riggs wrote:
Tom Lane writes
In the second place, what the code is doing is dependent on an
understanding
of the semantics of IN; I'm not sure it's applicable to, say,
WHERE outervar ANY (SELECT innervar FROM ...)
and it's definitely not applicable to
WHERE outervar ALL
Hi
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
select a.* from test1 a, (select id from test1 order by num) as b where
a.id = b.id;
There is no constraint on the order of 'a', so why is pull_up_subqueries
Bruno Wolff III wrote:
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney [EMAIL PROTECTED] wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation.
Then why spend time
12 matches
Mail list logo
