From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Yang Zhang <yanghatespam(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Sorting performance vs. MySQL |
Date: | 2010-02-22 19:54:20 |
Message-ID: | dcc563d11002221154h19175206x2104b1e24d0a60cf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Feb 22, 2010 at 12:50 PM, Yang Zhang <yanghatespam(at)gmail(dot)com> wrote:
> On Mon, Feb 22, 2010 at 2:39 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>> On Mon, Feb 22, 2010 at 12:30 PM, Yang Zhang <yanghatespam(at)gmail(dot)com> wrote:
>>> This isn't some microbenchmark. This is part of our actual analytical
>>> application. We're running large-scale graph partitioning algorithms.
>>
>> It's important to see how it runs if you can fit more / most of the
>> data set into memory by cranking up work_mem to something really big
>> (like a gigabyte or two) and if the query planner can switch to some
>> sort of hash algorithm.
>
> We're actually using a very small dataset right now. Being bounded by
> memory capacity is not a scalable approach for our application.
But the more you can fit into work_mem the faster it will go anyway.
So it's still worth a try.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Kretschmer | 2010-02-22 19:59:00 | Re: Info about concurrent sequential scans |
Previous Message | Yang Zhang | 2010-02-22 19:53:29 | Re: Sorting performance vs. MySQL |