On Mon, Oct 5, 2009 at 9:58 AM, Omar Kilani omar.kil...@gmail.com wrote:
Hi Xia,
Try this patch:
http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
It's a hack, but it works for us. I think you're probably spending
most of your query time planning, and this patch helps speed
On Fri, Oct 09, 2009 at 08:31:54PM +0800, Xia Qingran wrote:
On Mon, Oct 5, 2009 at 9:58 AM, Omar Kilani omar.kil...@gmail.com wrote:
Hi Xia,
Try this patch:
http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
It's a hack, but it works for us. I think you're probably
On Sun, Oct 4, 2009 at 9:58 PM, Omar Kilani omar.kil...@gmail.com wrote:
Hi Xia,
Try this patch:
http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
It's a hack, but it works for us. I think you're probably spending
most of your query time planning, and this patch helps speed
Robert,
On Mon, Oct 5, 2009 at 11:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Oct 4, 2009 at 9:58 PM, Omar Kilani omar.kil...@gmail.com wrote:
Hi Xia,
Try this patch:
http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
It's a hack, but it works for us. I think you're
On Mon, Oct 5, 2009 at 1:24 PM, Omar Kilani omar.kil...@gmail.com wrote:
I'm not really sure what the alternatives are -- it never really makes
sense to get the selectivity for thousands of items in the IN clause.
I've never seen a different plan for the same query against a DB with
that
Hi Xia,
Try this patch:
http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
It's a hack, but it works for us. I think you're probably spending
most of your query time planning, and this patch helps speed things up
10x over here.
Regards,
Omar
On Sun, Sep 27, 2009 at 5:13 PM, Xia
Xia Qingran wrote:
On Sun, Sep 27, 2009 at 1:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Xia Qingran qingran@gmail.com 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
On Sun, Sep 27, 2009 at 1:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Xia Qingran qingran@gmail.com 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
On Sat, Sep 26, 2009 at 10:59 PM, Craig James
craig_ja...@emolecules.com wrote:
If your user_id is always in a narrow range like this, or even in any range
that is a small fraction of the total, then add a range condition, like
this:
select * from event where user_id = 500 and user_id = 0
I have a big performance problem in my SQL select query:
select * from event where user_id in
Hi,
I have a big performance problem in my SQL select query:
select * from event where user_id in
Xia Qingran qingran@gmail.com 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 runtime is only about 240ms.
So either the
if you reuse that set a lot, how about storing it in a table , and doing the
join on db side ? if it is large, it sometimes makes sense to create temp
table just for single query (I use that sort of stuff for comparing with few
M records).
But temp tables in that case have to be short lived, as
Xia Qingran wrote:
Hi,
I have a big performance problem in my SQL select query:
select * from event where user_id in
On 26-Sep-2009, at 10:16 PM, Claus Guttesen wrote:
I have a big performance problem in my SQL select query:
select * from event where user_id in
15 matches
Mail list logo
