PostgreSQL versions: 7.4.3, 8.0.0beta1
Joins against set-returning functions can be slow. Here's a simple
example (in 8.0.0beta1, the gen_series function can be replaced
with generate_series):
CREATE FUNCTION gen_series(INTEGER, INTEGER) RETURNS SETOF INTEGER AS '
DECLARE
xstart ALIAS
Tom Lane wrote:
Martin Foster <[EMAIL PROTECTED]> writes:
The one not using sub-queries under EXPLAIN ANALYZE proves itself to be
less efficient and have a far higher cost then those with the penalty of
a sub-query. Since this seems to be counter to what I have been told
in the past, I thought
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Is the planner doing something wrong here?
Hard to see how it can be very smart with no idea about what the
function is going to return :-(.
I'd say that the mergejoin plan is actually a good choice given the
limited amount of info, because it has the le
Using this SQL:
EXPLAIN ANALYZE
SELECT DISTINCT
sessionid,
'2004-33' AS "yearweek",
nd.niveau
INTO TEMP
distinct_session
FROM
httplog h ,niveaudir nd
WHERE
hitDateTime>('now'::timestamp with time zone-'1440 min'::interval)
and h.hostid=(selec
Ole Tange <[EMAIL PROTECTED]> writes:
> As I read it the output tells me what was done during the milliseconds:
No, you have a fundamental misconception here. The notation means that
the first output row from a plan step was delivered after X
milliseconds, and the last row after Y milliseconds.
On Sun, Aug 15, 2004 at 07:47:53PM +0200, Ole Tange wrote:
> QUERY PLAN
> -
> Unique (cost=5680.00..5766.70 rows=8670 width=26) (act
On Sun, 15 Aug 2004, Tom Lane wrote:
> Ole Tange <[EMAIL PROTECTED]> writes:
> > As I read it the output tells me what was done during the milliseconds:
>
> No, you have a fundamental misconception here. The notation means that
> the first output row from a plan step was delivered after X
> mill
Ole Tange <[EMAIL PROTECTED]> writes:
> Now I am curious: Why isn't DISTINCT implemented using a Hash aggregate?
Partly lack of round tuits, partly the fact that it is closely
intertwined with ORDER BY and I'm not sure what side-effects would
arise from separating them. In particular, the DISTINC
You're not getting much of a bump with this server. The CPU is
incrementally faster -- in the absolutely best case scenario where your
queries are 100% cpu-bound, that's about ~25%-30% faster.
What about using Dual Athlon MP instead of a Xeon? Would be much less expensive,
but have higher performa
