"Peter J. Holzer" writes:
> Seems plausible. Also I'm wondering what CPU this is: 36 seconds for an
> in-memory sort of 900k rows seems slow to me.
I'm wondering if it's textual data in some locale whose strcoll() behavior
is exceptionally slow.
regards, tom lane
--
Se
On 2015-11-25 19:35:15 +0300, Evgeniy Shishkin wrote:
> Fast:
>
> Sort (cost=193101.41..195369.80 rows=907357 width=129) (actual
> time=3828.176..3831.261 rows=43615 loops=1)
>Output: dim_cliente.tipocliente, dim_cliente.a1_ibge, dim_cliente.a1_cod,
> dim_cliente.a1_nome, dim_vendedor.a3_n
My database version is 9.3 but I have test with 9.4 too with the same
result, and I have test changing that parameter without success.
I want to know what does have to do the trim with the different query plans?
2015-11-25 13:35 GMT-03:00 Evgeniy Shishkin :
> > What is your Postgres version?
> >
> What is your Postgres version?
> Do you have correct statistics on this tables?
> Please show yours execution plans with buffers i.e. explain
> (analyze,buffers) ...
>
Fast:
Sort (cost=193101.41..195369.80 rows=907357 width=129) (actual
time=3828.176..3831.261 rows=43615 loops=1)
Outp
On 25.11.2015 17:15, Blas Pico wrote:
I have a query that produce a different query plan if I put a trim in
one of the columns in the order by.
When i put the trim in any column it use hashaggregate and took 3
seconds against 30 when not.
Is wear because the columns is clean not need to
I have a query that produce a different query plan if I put a trim in one
of the columns in the order by.
When i put the trim in any column it use hashaggregate and took 3 seconds
against 30 when not.
Is wear because the columns is clean not need to be trimmed, I have check
that.
The problem
