Re: [PATCH] Use optimized single-datum tuplesort in ExecSort

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: James Coleman <jtc331(at)gmail(dot)com>, Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: [PATCH] Use optimized single-datum tuplesort in ExecSort
Date: 2021-07-21 01:15:19
Message-ID: CAApHDvqhUYHYGmovoGWJQ1+Z+50Mz=PV6bW=QYEh3Z+wZTufPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 20 Jul 2021 at 23:28, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> I took a look at cost_tuplesort and I think that some small adjustments could be made as part of the improvement process.
> It is attached.
> 1. long is a very problematic type; better int64?
> 2. 1024 can be int, not long?
> 3. 2 changed all to 2.0 (double)?
> 4. If disk-based is not needed, IMO can we avoid calling relation_byte_size?
>
> Finally, to at least document (add comments) those conclusions,
> would be nice, wouldn't it?

I don't think there's anything useful here. If you think otherwise,
please take it to another thread. Also, I'd recommend at least
compiling any patches you send to -hackers in the future. Going by the
CF bot, this one does not.

You might also want to read up on type promotion rules in C. Your
sort_mem calculation change does not do what you think it does. Class
it as homework to figure out what's wrong with it. No need to report
your findings here. Just thought it would be useful for you to learn
those things.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-07-21 01:32:18 Re: Bitmap reuse
Previous Message Yugo NAGATA 2021-07-21 01:15:09 Re: Question about non-blocking mode in libpq