In the original example it looks like using the index (and not running
a parallel query) is what made the query slow
The fast version was brute-force sequscan(s) + sort with 3 parallel
backends (leader + 2 workers) sharing the work.
On Tue, Mar 2, 2021 at 10:42 PM David Rowley wrote:
>
> On Wed
On Wed, 3 Mar 2021 at 10:04, Michael Lewis wrote:
> Are there guidelines or principles you could share about writing the group by
> clause such that it is more efficient?
If you have the option of writing them in the same order as an
existing btree index that covers the entire GROUP BY clause (i
>
> If we want to do anything much smarter than that like trying every
> combination of the GROUP BY clause, then plan times are likely going
> to explode. The join order search is done based on the chosen query
> pathkeys, which in many queries is the pathkeys for the GROUP BY
> clause (see standa
On Tue, 2 Mar 2021 at 21:53, Liu, Xinyu wrote:
> *Expected Behavior
>
> Since these two queries are semantically equivalent, we were hoping that
> PostgreSQL would evaluate them in roughly the same amount of time.
> It looks to me that different order of group by clauses triggers different
> pla
út 2. 3. 2021 v 9:53 odesílatel Liu, Xinyu napsal:
>
>
>
>
>
>
>
>
>
>
> * Hello, We have 2 TPC-H queries which fetch the same tuples but have
> significant query execution time differences (4.3 times). We are sharing a
> pair of TPC-H queries that exhibit this performance difference: First
> que
