Re: [PERFORM] Analyze and default_statistics_target

2013-01-21 Thread Albe Laurenz
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

Re: [PERFORM] Analyze and default_statistics_target

2013-01-21 Thread Heikki Linnakangas
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

[PERFORM] Analyze and default_statistics_target

2013-01-21 Thread AJ Weber
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

Re: [PERFORM] Analyze on temp table taking very long

2011-03-29 Thread Mahadevan, Mridula
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

Re: [PERFORM] Analyze on temp table taking very long

2011-03-22 Thread Tom Lane
"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

[PERFORM] Analyze on temp table taking very long

2011-03-22 Thread Mahadevan, Mridula
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

Re: [PERFORM] analyze

2008-01-29 Thread Scott Marlowe
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

Re: [PERFORM] analyze

2008-01-29 Thread Andrew Sullivan
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

[PERFORM] analyze

2008-01-29 Thread Adrian Moisey
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

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Tom Lane
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

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Jacek Rembisz
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

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Tom Lane
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

[PERFORM] Analyze makes queries slow...

2003-08-14 Thread Stef
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

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Tom Lane
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.

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Stef
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

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Stef
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.