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
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
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
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
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:/
