Re: trying to study how sorting works - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: trying to study how sorting works
Date
Msg-id 55146ACA.8010803@BlueTreble.com
Whole thread Raw
In response to trying to study how sorting works  (hitesh ramani <hiteshramani@hotmail.com>)
List pgsql-hackers
On 3/26/15 12:14 PM, hitesh ramani wrote:
> Hello devs,
>
> I'm trying to understand how sorting exactly works in Postgres, I've
> understood that there are two sorting mechanisms depending on the size
> of the data, one being qsort which is initiated if workmem is < 1024 kb

That's incorrect. What happens is we absorb tuples in memory until we 
would exceed work_mem. At that point the sort switches to a tapesort.

> and the other being external sort which is initiated in the other case.
> I tried to find out more material to understand how it exactly works but
> I'm unable to find any help material.

Take a look at utils/sort/tuplesort.c and executor/nodeSort.c (both 
under src/backend).

> Moreover, I'm trying to study the code using gdb by attaching it to the
> pg_backend_pid and having a breakpoint at raw_parser, from where I start
> analyzing. Any help material or resources would be really appreciated.

FWIW, I typically set a breakpoint at exec_simple_query when I want to 
do that, and skip over functions until either 
pg_analyze_and_rewrite->parse_analyze->transformTopLevelStmt or 
PortalRun. The first case is useful if you're dealing with something 
that's going to get handled entirely during query analysis, such as 
casting a constant or utility commands. PortalRun is what you want when 
there will be some kind of output, including DML.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
Next
From: Gavin Flower
Date:
Subject: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0