From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: CPU cost of operators |
Date: | 2009-09-30 20:14:29 |
Message-ID: | 603c8f070909301314s125329a4p2e898a0e9f5f7979@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Sep 30, 2009 at 4:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 30, 2009 at 1:12 PM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
>>
>> Episode umpteen of the ongoing saga with my GiST indexes.
>>
>> For some reason, GiST uses loads of CPU. I have a query that runs entirely
>> out of cache, and it takes ages. This much I have tried to fix and failed so
>> far.
>>
>> What I would now like to do is to tell postgres about it, so that the
>> EXPLAINs are correct. Is there a way to tell Postgres that an operator has a
>> large CPU cost? I can tell it what the join selectivity is, but I can't find
>> anything about CPU cost.
>
> Not that I know of, but seems like it would be a reasonable extension.
Er, wait... if you set the 'COST' parameter for the backing function,
does that work?
.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-30 20:35:29 | Re: CPU cost of operators |
Previous Message | Robert Haas | 2009-09-30 20:13:29 | Re: CPU cost of operators |