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
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? |