Re: ANALYZE patch for review

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: ANALYZE patch for review
Date: 2004-03-15 16:10:07
Message-ID: 23619.1079367007@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-03-15 16:14:24 Re: initdb problen
Previous Message Bruce Momjian 2004-03-15 15:58:21 Re: remove log_timestamp, log_pid and log_source_port GUC