Skip site navigation (1) Skip section navigation (2)

Re: Stopgap solution for table-size-estimate updatingproblem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Stopgap solution for table-size-estimate updatingproblem
Date: 2004-11-29 15:37:32
Message-ID: 18457.1101742652@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> writes:
> Tom wrote:
>>> But I am used to applications
>>> that prepare a query and hold the plan for days or weeks. If you happen to 
>>> create the plan when the table is by chance empty you lost.
>> 
>> You lose in either case, since this proposal doesn't change when
>> planning occurs or doesn't occur.

> This is not true in my case, since I only "update statistics"/analyze
> when the tables have representative content (i.e. not empty).

I'm unsure why you feel you need a knob to defeat this.  The only time
when the plan would change from what you think of as the hand-tuned
case is when the physical table size is greatly different from what it
was when you analyzed.  The entire point of wanting to make this change
is exactly that in that situation the plan *does* need to change.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-11-29 15:42:29
Subject: Re: multiline CSV fields
Previous:From: Simon RiggsDate: 2004-11-29 15:16:57
Subject: Basic Requirements for SQL Window Functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group