On Wed, 2008-05-28 at 16:59 -0700, Josh Berkus wrote:
sort_mem: My tests with 8.2 and DBT3 seemed to show that, due to
limitations of our tape sort algorithm, allocating over 2GB for a single
sort had no benefit. However, Magnus and others have claimed otherwise.
Has this improved in
Vlad Arkhipov [EMAIL PROTECTED] writes:
EXPLAIN ANALYZE
SELECT *
FROM i
WHERE d BETWEEN '2007-05-12' AND '2007-05-12'
Index Scan using i_d on i (cost=0.00..2.39 rows=1 width=402) (actual
time=0.053..4.284 rows=1721 loops=1)
Index Cond: ((d = '2007-05-12'::date) AND (d =
Simon,
There is an optimum for each specific sort.
Well, if the optimum is something other than as much as we can get, then we
still have a pretty serious issue with work_mem, no?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-performance mailing list
Josh Berkus [EMAIL PROTECTED] writes:
Simon,
There is an optimum for each specific sort.
Well, if the optimum is something other than as much as we can get, then we
still have a pretty serious issue with work_mem, no?
With the sort algorithm. The problem is that the database can't predict
