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 ver
130 rows=37 loops=424)
Index Cond: (activity_activityevent.user_id = u0.user_id)
Total runtime: 165.323 ms
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)?
Eugene
--
Sent via pgsql-performance mailing list (pgsq
What about "Daffodil Replicator" - GPL -
http://sourceforge.net/projects/daffodilreplica/
--
Thanks,
Eugene Ogurtsov
Internal Development Chief Architect
SWsoft, Inc.
Craig A. James wrote:
Looking for replication solutions, I find:
Slony-I
Seems good, single master only, m
.8Ghz
* 6GB RAM (2 GB for OS and DB, 4GB for Application)
* RAID-10 w/ 6x72GB 15.000rpm HDDs
--
Thanks,
Eugene Ogurtsov
Internal Development Chief Architect
SWsoft, Inc.
I have a very simple problem. I run two select statments, they are identical except
for a single
where condition. The first select statment runs in 9 ms, while the second statment
runs for 4000
ms
SQL1 - fast 9ms
explain analyse select seq_ac from refseq_sequence S where seq_ac in (select seq_a
