AJ Weber wrote:
> What is the unit-of-measure used for default_statistics_target?
Number of entries in pg_stats.histogram_bounds orpg_stats.most_common_vals.
Yours,
Laurenz Albe
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
h
On 21.01.2013 17:29, AJ Weber wrote:
I was under the impression that the default_statistics_target was a
percentage of rows to analyze. Maybe this is not the case?
Nope.
I ran an analyze during a "quiet point" last night and for a few of my
large tables, I didn't get what I consider a reasona
I was under the impression that the default_statistics_target was a
percentage of rows to analyze. Maybe this is not the case?
I ran an analyze during a "quiet point" last night and for a few of my
large tables, I didn't get what I consider a reasonable sampling of
rows. When running with "v
sql-performance@postgresql.org
Subject: Re: [PERFORM] Analyze on temp table taking very long
"Mahadevan, Mridula" writes:
> This has been running fine for a while on multiple setups, large and small
> volumes. The setups all have the same hardware configuration.
> On one partic
"Mahadevan, Mridula" writes:
> This has been running fine for a while on multiple setups, large and small
> volumes. The setups all have the same hardware configuration.
> On one particular setup with about 200k records and this analyze runs for
> 45min and then times out(statement timeout is s
I have a function where in
In a cursor loop I
1. create a temp table (on commit drop)
2. insert data into it
3. Run Analyze on the table
Select/update outside the loop.
This has been running fine for a while on multiple setups, large and small
volumes. The setups all have
On Jan 29, 2008 8:28 AM, Adrian Moisey <[EMAIL PROTECTED]> wrote:
> Hi
>
> How long is a piece of string?
>
> While we're at it, how often do I vacuum analyze?
>
> Seriously though, how do I try measure this?
1: Turn on autovacuum.
2: Look up the thread on nagios plugins for pgsql and rip the quer
On Tue, Jan 29, 2008 at 04:28:45PM +0200, Adrian Moisey wrote:
>
> Seriously though, how do I try measure this?
Is autovacuum not going to work for your case?
A
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
Hi
How long is a piece of string?
While we're at it, how often do I vacuum analyze?
Seriously though, how do I try measure this?
--
Adrian Moisey
System Administrator | CareerJunction | Your Future Starts Here.
Web: www.careerjunction.co.za | Email: [EMAIL PROTECTED]
Phone: +27 21 686 6820 | M
Stef <[EMAIL PROTECTED]> writes:
> => Could we see the results of "EXPLAIN ANALYZE", rather than just EXPLAIN,
> => for the un-analyzed case?
> Attached the output of this.
Hmm... not immediately obvious where it's going wrong. Could you try
this (after ANALYZE):
set enable_mergejoin t
On Mon, Aug 11, 2003 at 03:58:41PM +0200, Stef wrote:
> I have attached an sql statement that normally runs under 3 minutes.
> That is, until I vacuum analyze the database (or just the tables in the query),
> then the same query runs longer than 12 hours, and I have to kill it.
Hmm, I have notice
Stef <[EMAIL PROTECTED]> writes:
> I have attached an sql statement that normally runs under 3 minutes.
> That is, until I vacuum analyze the database (or just the tables in the query),
> then the same query runs longer than 12 hours, and I have to kill it.
Could we see the results of "EXPLAIN ANA
Hi all,
I posted this problem on the sql list, and was referred to this list in stead.
I have attached an sql statement that normally runs under 3 minutes.
That is, until I vacuum analyze the database (or just the tables in the query),
then the same query runs longer than 12 hours, and I have to k
Stef <[EMAIL PROTECTED]> writes:
> => And what PG version is this, exactly?
> PostgreSQL 7.3.1
Ah, I think I see it: you are getting burnt by a mergejoin estimation
bug that was fixed in 7.3.2. Please update (you might as well go to
7.3.4 while you're at it) and see if the results improve.
Hi Tom,
Thanks for responding.
I got as much info as I could :
On Mon, 11 Aug 2003 11:43:45 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
=> Could we see the results of "EXPLAIN ANALYZE", rather than just EXPLAIN,
=> for the un-analyzed case?
Attached the output of this.
=> Also, what do you see
On Mon, 11 Aug 2003 14:25:03 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
=> set enable_mergejoin to off;
=> explain analyze ... query ...
=>
=> If it finishes in a reasonable amount of time, send the explain output.
Hi again,
I did this on the 7.3.1 database, and attached the output.
16 matches
Mail list logo