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 <= '2007-
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 (pgsql-performance@
"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 c
