Hi,
On 27.8.2013 06:06, Adam Ma'ruf wrote:
> Hi
>
> Thanks for the response. I reran the query but first ran the statement
> you provided and set working mem to 2gb. It ended up taking 133s and
> group aggregate was still used
OK.
>
> Here are the values you asked for:
> # - Planner Method C
Hi
Thanks for the response. I reran the query but first ran the statement you
provided and set working mem to 2gb. It ended up taking 133s and group
aggregate was still used
Here are the values you asked for:
# - Planner Method Configuration -
#enable_bitmapscan = on
#enable_hashagg = on
#enab
On 26 Srpen 2013, 15:02, Adam Ma'ruf wrote:
> Sure
>
> I just upgraded to 9.2.4. The query is:
> SELECTquebec_four
> , sierra
> , SUM(dollaramount) as dollaramount
> FROM alpha_quebec_echo
> GROUP BY quebec_four
> , sierra
>
> alpha_quebec_echo ha
Sure
I just upgraded to 9.2.4. The query is:
SELECTquebec_four
, sierra
, SUM(dollaramount) as dollaramount
FROM alpha_quebec_echo
GROUP BY quebec_four
, sierra
alpha_quebec_echo has 5,409,743 rows and 39 columns. Quebec_four and
sierra are bot
Hello
It is little bit strange - can you send a info about your PostgreSQL
version, send a query, and table description?
In this case, PostgreSQL should to use a hash aggregate, but from some
strange reason, pg didn't do it.
Second strange issue is speed of external sort - it is less than I can
Hi,
I wasn't whether or not to mail to the novice mailing list of this one.
Since this is performance related I'm posting it here, but I am definitely
a novice at postgresql - converting from mssql just now.
I have a ~2.5gb table with ~5M rows of data. A query that groups by two
fields and sums
