public inbox for [email protected]  

help / color / mirror / Atom feed

From: Teodor Sigaev <[email protected]>
To: Tomas Vondra <[email protected]>
To: Pgsql Hackers <[email protected]>
Subject: Re: POC: GROUP BY optimization
Date: Wed, 13 Jun 2018 19:56:00 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

> I.e. we already do reorder the group clauses to match ORDER BY, to only
> require a single sort. This happens in preprocess_groupclause(), which
> also explains the reasoning behind that.
Huh. I missed that. That means group_keys_reorder_by_pathkeys() call inside 
get_cheapest_group_keys_order() duplicates work of preprocess_groupclause().
  And so it's possible to replace it to simple counting number of the same 
pathkeys in beginning of lists. Or remove most part of preprocess_groupclause() 
- but it seems to me we should use first option, preprocess_groupclause() is 
simpler, it doesn't operate with pathkeys only with  SortGroupClause which is 
simpler.

BTW, incremental sort path provides pathkeys_common(), exactly what we need.

> I wonder if some of the new code reordering group pathkeys could/should
> be moved here (not sure, maybe it's too early for those decisions). In
> any case, it might be appropriate to update some of the comments before
> preprocess_groupclause() which claim we don't do certain things added by
> the proposed patches.

preprocess_groupclause() is too early step to use something like 
group_keys_reorder_by_pathkeys() because pathkeys is not known here yet.


> This probably also somewhat refutes my claim that the order of grouping
> keys is currently fully determined by users (and so they may pick the
> most efficient order), while the reorder-by-ndistinct patch would make
> that impossible. Apparently when there's ORDER BY, we already mess with
> the order of group clauses - there are ways to get around it (subquery
> with OFFSET 0) but it's much less clear.

I like a moment when objections go away :)

-- 
Teodor Sigaev                                   E-mail: [email protected]
                                                    WWW: http://www.sigaev.ru/

view thread (89+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: POC: GROUP BY optimization
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox