On Sun, Dec 4, 2016 at 4:09 PM, Tom Lane wrote:
> Of course, we would also have to teach cost_sort or someplace near there
> that non-C sorting is much more expensive than C-collation sorting. Not
> sure about exactly how to set that up without it being a kluge.
We've talked about that before, i
Peter Geoghegan writes:
> I wonder what it would take to teach the optimizer to consider the
> possibility of a "collation strength reduction". In other words, for
> aggregates that perform a sort (or for aggregates that rely on the
> presence of a sort node without there being some other dependen
2016-12-04 23:12 GMT+01:00 Peter Geoghegan :
> On Sat, Dec 3, 2016 at 5:20 PM, Tomas Vondra
> wrote:
> > So the sort is probably slow because of CPU, as it compares strings. In
> > some locales that may be very expensive - not sure which locale is used
> > in this case, as it was not mentioned.
>
On Sat, Dec 3, 2016 at 5:20 PM, Tomas Vondra
wrote:
> So the sort is probably slow because of CPU, as it compares strings. In
> some locales that may be very expensive - not sure which locale is used
> in this case, as it was not mentioned.
I wonder what it would take to teach the optimizer to co
On Sat, 2016-12-03 at 13:08 -0500, Kiriakos Georgiou wrote:
> The array_agg() has nothing to do with it. It’s the group by.
> Without knowing what you are conceptually trying to accomplish, I
> can’t say much.
It *IS* caused by array_agg(). PostgreSQL can only do HashAggregate
when everything fit
:
Subject: [GENERAL] Avoid sorting when doing an array_agg
I have a users table which contains ~70 million rows that looks like this:
Column| Type|
-+---+
id | integer |
first_name | character varying |
last_name
I have a users table which contains ~70 million rows that looks like this:
Column| Type|
-+---+
id | integer |
first_name | character varying |
last_name | character varying |
category_id | integer |
Indexes:
