Re: Planner estimates and cast operations ,...

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planner estimates and cast operations ,...
Date: 2006-09-04 17:04:44
Message-ID: 20060904170444.GA8543@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 04, 2006 at 17:19:37 +0200,
Hans-Juergen Schoenig <postgres(at)cybertec(dot)at> 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 with.

> out of disk space as well. this is a 600 gb biest :(

I wouldn't expect this to be a problem. If you have 10^9 rows, I would expect
the index to be less than 10% of you current size. If you are so close to
your disk space limit that that is a problem, you have a problem in any case.

>
> what about the planner approach?
> this would solve the problem for some other issues as well. an index
> might not be flexible enough :(.

If you disable sorting you might be able to get it to switch plans. Lying
about the amount of work memory so that the planner thinks the hash
will fit in memory despite its misguessing the number of buckets might also
help.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Bernier 2006-09-04 17:09:10 Re: On Certification (was Re: [GENERAL] Thought provoking piece on NetBSD)
Previous Message Mark Cave-Ayland 2006-09-04 16:15:57 Re: Hierarchical Queries--Status