Віталій Тимчишин writes:
> I'd prefer ALTER VIEW SET ANALYZE=true; or CREATE/DROP ANALYZE ;
> Also it should be possible to change statistics target for analyzed
> columns.
Yeah, my idea was ALTER VIEW ENABLE ANALYZE; but that's an easy
point to solve if the idea proves helpful.
> Such a stat
I'd prefer ALTER VIEW SET ANALYZE=true; or CREATE/DROP ANALYZE ;
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
queries
On Sat, Jun 6, 2009 at 4:50 AM, Simon Riggs 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 specifically analyze the
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 can
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 prod
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
On Wed, Jun 3, 2009 at 8: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 som
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 6:04 PM, Janine Sisk 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 be more specif
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.
Janine Sisk 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 the problem a
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 c
12 matches
Mail list logo