Robert Haas writes:
> Er, wait... if you set the 'COST' parameter for the backing function,
> does that work?
It's supposed to...
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http:/
On Wed, Sep 30, 2009 at 4:13 PM, Robert Haas wrote:
> On Wed, Sep 30, 2009 at 1:12 PM, Matthew Wakeling 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
On Wed, Sep 30, 2009 at 1:12 PM, Matthew Wakeling 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 wou
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
EXPLAI
Xia Qingran wrote:
On Sun, Sep 27, 2009 at 1:03 AM, Tom Lane wrote:
Xia Qingran writes:
I have a big performance problem in my SQL select query:
select * from event where user_id in
(500,499,498, ... ,1,0);
The above SELECT always spends 1200ms.
Your EXPLAIN ANALYZE shows that the actual run
