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
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 |