Re: ANALYZE patch for review - Mailing list pgsql-patches

From Tom Lane
Subject Re: ANALYZE patch for review
Date
Msg-id 23619.1079367007@sss.pgh.pa.us
Whole thread Raw
In response to Re: ANALYZE patch for review  ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>)
List pgsql-patches
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes:
> 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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: remove log_timestamp, log_pid and log_source_port GUC
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] initdb problen