On Oct 21, 2007, at 10:40 AM, Martijn van Oosterhout wrote:
On Sun, Oct 21, 2007 at 07:36:00AM -0400, Bill Moran wrote:
What version of PG are you using and what is your shared_buffers
setting?
With 8G of RAM, you should start with shared_buffers around 2 -
3G, if
you're using a modern version of PG. With that much shared memory, a
large portion of that index should stay in RAM, as long as it's being
used often enough that PG doesn't swap it for other data.
With that much memory, the index is likely to remain in memory no
matter what size shared_memory he has. Anything in shared_memory is
going to be in the system cache anyway. I wonder if there's something
else we havn't been told, like how big the actual table is and whether
there are any other large tables/indexes.
The table itself is about 10M rows corresponding to 14GB. The only
other index on this table is a btree index whose size is ~300MB. The
machine is not running anything else.
Now, it might just be the case that given the size of the index, I
cannot make bounding box queries (which will use the CUBE index) go
any faster. But I am surprised that that the other type of query
(using cube_distance which by definition must use a seq scan) is only
slightly longer. If nothing else, scanning through 14GB of data
should be 3 times slower than scanning through 3GB of data.
-------------------------------------------------------------------
Rajarshi Guha <rguha@xxxxxxxxxxx>
GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE
-------------------------------------------------------------------
All laws are simulations of reality.
-- John C. Lilly
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
