| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Yang Zhang <yanghatespam(at)gmail(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Sorting performance vs. MySQL |
| Date: | 2010-02-22 20:44:23 |
| Message-ID: | 1079.1266871463@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Yang Zhang <yanghatespam(at)gmail(dot)com> writes:
> On Mon, Feb 22, 2010 at 1:13 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> the speed depends on setting of working_memory. Try to increase a working_memory
> It's already at
> 20000kB
According to your original posting, you're trying to sort something like
a gigabyte of data. 20MB is peanuts. I wouldn't recommend increasing
the value across-the-board, but setting it to several hundred meg for
this particular query might help. How much RAM in your machine anyway?
Also, the fact that mysql is faster suggests that having an index does help.
Possibly the data is nearly ordered by transactionid, in which case an
indexscan would not have random-access problems and would be much faster
than an explicit sort.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2010-02-22 20:45:13 | Re: Sorting performance vs. MySQL |
| Previous Message | Yeb Havinga | 2010-02-22 20:37:55 | Re: Sorting performance vs. MySQL |