i am looking at some corner case which might also cause troubles for
other people.
consider the following:
SELECT some_timestamp::date FROM very_large_table GROUP BY
some_timestamp::date
my very_large_table is around 1billion entries.
the problem is: the planner has a problem here as it
Hans-Juergen Schoenig [EMAIL PROTECTED] writes:
consider the following:
SELECT some_timestamp::date FROM very_large_table GROUP BY
some_timestamp::date
my very_large_table is around 1billion entries.
the problem is: the planner has a problem here as it is taking the
(correct)
hi tom ...
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the table and i would run
out of disk space as well. this is a 600 gb biest :(
what about the planner approach?
this would solve the
On Mon, Sep 04, 2006 at 17:19:37 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the table and i would run
That may be hard to deal
On Sep 4, 2006, at 7:04 PM, Bruno Wolff III wrote:
On Mon, Sep 04, 2006 at 17:19:37 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
i thought about creating an index on the expression but the problem
is that this is hardly feasable.
in 8.0 (what i have here) this would block the
On Mon, Sep 04, 2006 at 19:09:16 +0200,
Hans-Juergen Schoenig [EMAIL PROTECTED] wrote:
setting work_mem to 2gb does not help here ;)
set it to the max value on 8.0.
this was my first try too.
the problem is - there is no magic switch to mislead the planner a
little without hacking the