[postgis-devel] Re: geometry stats

[strk]

On Mon, Mar 15, 2004 at 04:37:22PM -0000, Mark Cave-Ayland wrote:
> Hi strk,
> 
> I emailed Tom to ask him about the vacuum_delay_point() on the
> pgsql-patches list and have included his reply below:
> 
> > > Having been working with the PostGIS team to implement a custom 
> > > analyze routine for R-Tree selectivity, we have a question regarding
> 
> > > the new
> > > vacuum_delay_point() which is present in analyze.c. Is it the
> > > responsibility of the programmers to remember to do a
> > > vacuum_delay_point() before calling the fetch_func(), or would it be
> > > better to move the vacuum_delay_point() into std_fetch_func()?
> >
> > It's probably not really necessary to call vacuum_delay_point in the
> analysis routine, 
> > unless you are contemplating extremely expensive analysis.  If you did
> have an expensive > loop, would std_fetch_func necessarily be called
> inside it?  It seems inappropriate to 
> > me to put vacuum_delay_point inside std_fetch_func --- it's the
> analysis programmer's 
> > business to understand whether it must be called, and if so where's an
> appropriate 
> > place.
> >
> >			regards, tom lane
> 
> 
> It's difficult to determine whether or not our processing justifies
> including this, although I would lean towards including it given that
> the standard stats functions do it this way.... what do you think?

I don't see any problem in including the call, I just wanted to
be sure we were approaching a stable interface.

We have two loops in the compute_geometry_stats() function.
The first fetches data from the db, the second works on
in-memory data and does the bigger work. I've put the
'breaks' in both loops. I did not bother to make the call
every N iterations, I assume vacuum_delay_point() will not
do anything if the time has not arrived to do something, right ?

--strk;

> 
> 
> Cheers,
> 
> Mark.
> 
> ---
> 
> Mark Cave-Ayland
> Webbased Ltd.
> Tamar Science Park
> Derriford
> Plymouth
> PL6 8BX
> England
> 
> Tel: +44 (0)1752 764445
> Fax: +44 (0)1752 764446
> 
> 
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender. You
> should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
> 
> > -----Original Message-----
> > From: strk [mailto:strk at keybit.net] 
> > Sent: 12 March 2004 14:13
> > To: Mark Cave-Ayland
> > Subject: Re: [postgis-devel] Re: geometry stats
> > 
> > 
> > I talked too early...
> > Taking a look at the pgsql-patches mailing list it seems
> > like the patch you're talking about is not well accepted.
> > I wouldn't introduce something we'll have to remove later.
> > 
> > Just another note. If the best place to call that function
> > from is just before fetchfunc(), why shouldn't fetchfunc() 
> > itself call the vacuum_delay_point() ?
> > 
> > --strk;
> > 
> > On Fri, Mar 12, 2004 at 01:05:50PM +0100, strk wrote:
> > > On Fri, Mar 12, 2004 at 11:23:04AM -0000, Mark Cave-Ayland wrote:
> > > > Hi strk,
> > > > 
> > > > Have just noticed one more thing with regard to the ANALYZE patch 
> > > > for 7.5 - it looks like we need to insert a vacuum_delay_point() 
> > > > just before the call to fetch_func() so that the recent vacuum 
> > > > throttling patch will actually work when ANALYZING 
> > geometry columns 
> > > > (compare with
> > > > compute_scalar_stats() in analyze.c) - what do you think?
> > > 
> > > It sounds kind enough.
> > > I'll committ the change as soon as I handle to compile latest PG-cvs
> > > 
> > > --strk;
> > 
>