2013/2/2 Casey Allen Shobe :
> However I was unable to adjust the statistics target using that command:
>
> alter table opportunity.census_user set statistics 500;
> ERROR: syntax error at or near "statistics"
> LINE 1: alter table opportunity.census_user set statistics 500;
I'm sorry for this, m
I'll get back to you on this Monday - I'm heading home for the week now.
However I was unable to adjust the statistics target using that command:
alter table opportunity.census_user set statistics 500;
ERROR: syntax error at or near "statistics"
LINE 1: alter table opportunity.census_user set st
2013/2/1 Casey Allen Shobe :
> Rowcounts are shown in the earlier paste link, but apparently I forgot to
> include the census table - hewitt_1_0_factors_precalc_new has 4,135,890
> rows, and census_user has 1846439 rows.
>
> Statistics target is the default at 100.
I would try the following:
ALTER
On Fri, Feb 1, 2013 at 4:12 PM, Виктор Егоров wrote:
> Estimated rows for ‘hewitt_1_0_factors_precalc_new’ are 1000x less then
> actual.
> And for ‘census_user’ estimation is 100x less, then actual.
>
> How many rows are in those tables and what is your statistics target?
>
Rowcounts are shown i
2013/2/1 Casey Allen Shobe :
> Hopefully some improvements to the planner can come from this information?
>
> Here is the CTE version of the query:
> http://pgsql.privatepaste.com/2f7fd3f669
> ...and here is it's explain analyze: http://explain.depesz.com/s/5ml
Estimated rows for ‘hewitt_1_0_fac
Rhodiumtoad on IRC helped me figure out how to move part of the query into
a CTE in order to work around the planner problem. This is a hack but it
brings the time down from many hours to 17 seconds, which is better than it
was even with the better plan in the first place! For some reason it
actu
On Fri, Feb 1, 2013 at 1:50 PM, Richard Huxton wrote:
> 1. You said config_id was now "smallint" in your email, but it reads "int"
> in the pastes above.
>Doesn't matter much which, but just checking we've got the right pastes.
>
You have the correct pastes. I did an alter to int in an atte
On 01/02/13 17:54, Casey Allen Shobe wrote:
My apologies - I included the wrong version of the query
before...during testing I had tried deparameterizing a few of the
input parameters. I also accidentally left out the schema for the
network_config_tot2 table from the initial paste.
Here is
My apologies - I included the wrong version of the query before...during
testing I had tried deparameterizing a few of the input parameters. I
also accidentally left out the schema for the network_config_tot2 table
from the initial paste.
Here is an updated paste, which shows the correct query i
So where I'm working, a performance issue was identified that affected many
functions, because the (SQL language) functions took an int argument used
it in a where clause against a column (config_id) that was stored in
varchar format, leading to an inefficient casting when the query was
parameteriz
10 matches
Mail list logo
