Grzegorz Jaśkiewicz writes:
> Learn it to not generate with "WITH IN (subq)", is this can be quite
> slow on postgresql. Use joins instead.
OK, I've split the query in two (can't make Django to generate JOIN in this
case) and it always uses index now. This immediately opened road for
other optim
Scott Marlowe writes:
> On Tue, Sep 8, 2009 at 8:12 AM, Eugene Morozov wrote:
> OK, you need to look a little deeper at what's happening here. The
> pgsql query planner looks at a lot of things to decide if to use seq
> scan or and index. If you look at your row estimates versus actual
> rows r
On Tue, Sep 8, 2009 at 8:12 AM, Eugene Morozov wrote:
> Hello,
>
> I have a following query (autogenerated by Django)
>
> SELECT activity_activityevent.id, activity_activityevent.user_id,
> activity_activityevent.added_on
> FROM activity_activityevent
> WHERE activity_activityevent.user_id IN (
>
Eugene Morozov wrote:
> Can anyone enlighten me? Should I set random_page_cost to 1.2
> permanently (I feel this is not a really good idea in my case)?
For it to pass as many rows as it did in the time that it did, most or
all of the "reads" were cached. If this is typically the case, at
lea
Learn it to not generate with "WITH IN (subq)", is this can be quite
slow on postgresql. Use joins instead.
looks like planner was wrong about rowcount in one place: Hash IN Join
(cost=2204.80..4809.31 rows=292 width=202) (actual
time=12.856..283.916 rows=15702 loops=1)
I have no idea why, proba
Hello,
I have a following query (autogenerated by Django)
SELECT activity_activityevent.id, activity_activityevent.user_id,
activity_activityevent.added_on
FROM activity_activityevent
WHERE activity_activityevent.user_id IN (
SELECT U0.user_id
FROM profile U0
INNER JOIN profile_frien
