Обсуждение: Understanding sort's memory/disk usage

Hello,
Please reference these explain plans.  This is Pg 8.4.1

http://explain-analyze.info/query_plans/4032-query-plan-2745
http://explain-analyze.info/query_plans/4033-query-plan-2746

First, could somebody explain what is leading the first query to choose
a different plan that's much slower?  In the first plan only, this
expression is in the select & group by:

s.store_num || ' - ' || s.title

These are both non-null varchar fields.  Both have a unique index.

Second, why would it choose to sort on disk for what appears to be ~32MB
of data, when my work_mem and temp_buffers are both 64 MB each?

If I increase work_mem and temp_buffers to 128 MB, I get a faster plan:

http://explain-analyze.info/query_plans/4034-query-plan-2747

But it's only reporting 92kb of memory used? Why don't I see numbers
between 64 MB and 128 MB for both the on-disk and in-memory plans?

Thanks,
Adam

Adam Rich <adam.r@sbcglobal.net> writes:
> Please reference these explain plans.  This is Pg 8.4.1

> http://explain-analyze.info/query_plans/4032-query-plan-2745
> http://explain-analyze.info/query_plans/4033-query-plan-2746

> First, could somebody explain what is leading the first query to choose
> a different plan that's much slower?

I think it's rejecting the HashAggregate plan because, with the
estimated-wider rows, the hash table is estimated to exceed work_mem.

> Second, why would it choose to sort on disk for what appears to be ~32MB
> of data, when my work_mem and temp_buffers are both 64 MB each?

The on-disk representation is more compact for various reasons.

> But it's only reporting 92kb of memory used? Why don't I see numbers
> between 64 MB and 128 MB for both the on-disk and in-memory plans?

You're not taking into account whether the sort is on pre-aggregation or
post-aggregation data.

            regards, tom lane