Grzegorz Jaśkiewicz gryz...@gmail.com 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
.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 (pgsql-performance@postgresql.org)
To make changes to your subscription:
http
Scott Marlowe scott.marl...@gmail.com writes:
On Tue, Sep 8, 2009 at 8:12 AM, Eugene Morozoveug...@cactus-mouse.com 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
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, master
* 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
