I'd prefer ALTER VIEW name SET ANALYZE=true; or CREATE/DROP ANALYZE SQL;
Also it should be possible to change statistics target for analyzed columns.
Such a statement would allow to analyze multi-table correlations. Note that
for view planner should be able to use correlation information even for
Віталій Тимчишин tiv...@gmail.com writes:
I'd prefer ALTER VIEW name SET ANALYZE=true; or CREATE/DROP ANALYZE SQL;
Also it should be possible to change statistics target for analyzed
columns.
Yeah, my idea was ALTER VIEW name ENABLE ANALYZE; but that's an easy
point to solve if the idea
Hi,
Le 6 juin 09 à 10:50, Simon Riggs a écrit :
On Wed, 2009-06-03 at 21:21 -0400, Robert Haas wrote:
But, we're not always real clever about selectivity. Sometimes you
have to fake the planner out, as discussed here.
[...]
Fortunately, these kinds of problems are fairly rare, but they
On Sat, Jun 6, 2009 at 4:50 AM, Simon Riggssi...@2ndquadrant.com wrote:
The Function Index solution works, but it would be much better if we
could get the planner to remember certain selectivities.
I agree.
I'm thinking a command like
ANALYZE foo [WHERE ]
which would
On Wed, 2009-06-03 at 21:21 -0400, Robert Haas wrote:
But, we're not always real clever about selectivity. Sometimes you
have to fake the planner out, as discussed here.
http://archives.postgresql.org/pgsql-performance/2009-06/msg00023.php
Actually, I had to do this today on a
On 6/3/09 7:32 PM, Janine Sisk wrote:
I'm sorry if this is a stupid question, but... I changed
default_statistics_target from the default of 10 to 100, restarted PG,
and then ran vacuumdb -z on the database. The plan is exactly the same
as before. Was I supposed to do something else? Do I need
I've been Googling for SQL tuning help for Postgres but the pickings
have been rather slim. Maybe I'm using the wrong search terms. I'm
trying to improve the performance of the following query and would be
grateful for any hints, either directly on the problem at hand, or to
resources I
Janine Sisk jan...@furfly.net writes:
I've been Googling for SQL tuning help for Postgres but the pickings
have been rather slim. Maybe I'm using the wrong search terms. I'm
trying to improve the performance of the following query and would be
grateful for any hints, either directly on
Ok, I will look into gathering better statistics. This is the first
time I've had a significant problem with a PG database, so this is
uncharted territory for me.
If there is more info I could give that would help, please be more
specific about what you need and I will attempt to do so.
On Wed, Jun 3, 2009 at 6:04 PM, Janine Sisk jan...@furfly.net wrote:
Ok, I will look into gathering better statistics. This is the first time
I've had a significant problem with a PG database, so this is uncharted
territory for me.
If there is more info I could give that would help, please
I'm sorry if this is a stupid question, but... I changed
default_statistics_target from the default of 10 to 100, restarted PG,
and then ran vacuumdb -z on the database. The plan is exactly the
same as before. Was I supposed to do something else? Do I need to
increase it even further?
On Wed, Jun 3, 2009 at 8:32 PM, Janine Sisk jan...@furfly.net wrote:
I'm sorry if this is a stupid question, but... I changed
default_statistics_target from the default of 10 to 100, restarted PG, and
then ran vacuumdb -z on the database. The plan is exactly the same as
before. Was I
12 matches
Mail list logo
