Re: Sort method: external merge

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: wstrzalka <wstrzalka(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Sort method: external merge
Date: 2009-02-04 23:33:06
Message-ID: 1233790386.3805.96.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2009-02-04 at 02:15 -0800, wstrzalka wrote:
> Isn't it possible to sort only fields that order matters & some row
> identifier/position (don't really know what - oid/ctid are tight to
> table but something temporary tight to 'resultset')? It would take
> much less memory and could be processed in the work_mem more often.

ctid is not sufficient for all uses of Sort, because sometimes you are
sorting tuples that don't come from a table. Consider sorting the
results after a function has been applied to some other field -- how can
you get the result of that function?

What you're talking about is kind of like building an index on the fly.
You might as well just make a BTree normally, which is exactly the kind
of result structure you are suggesting: a sorted mapping between the
sort key and the ctid.

Even in the case where you already have an index, the index scan can
actually be more expensive. The reason is that accessing tuples in a
table by ctid is random access (except in the case of a clustered
table), while pulling the tuples from an external sort is more
sequential.

If you are interested, you can take this discussion to pgsql-hackers.

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Chris 2009-02-05 01:18:04 debugging plpgsql functions
Previous Message Grant Allen 2009-02-04 23:01:35 Re: Pet Peeves?