On Sun, Mar 06, 2005 at 11:27:35PM +0100, Dobrica Pavlinusic wrote:
> Index is opened on every select query.
I see where SwishClose() is called, but was curious it that would
always be called or if there might be a situation where the object
might be left open.
> One optimization that comes to mind is pool of open indexes in
> PostgreSQL back-end process. However, it dumps core on me often
> enough as-it, and I'm not for premature optimizations. I also don't
> have any idea how to make shared memory space (needed for such pool)
> in PostgreSQL back-end.
Maybe a linked list of open swish handles -- where each is identified
by the index file string used for the open. The tricky part is
getting them closed when no longer needed. Since I don't know
anything about postgres internals I can only wonder about how that
> > So having multiple error_or_abort_* functions might make that easier.
> Thanks for info. Is there any advantage in having errors checked via
> SW_SEARCH as opposed to SW_HANDLE? I just call Free_*_Object if I have
> handle. Is that enough?
I was just thinking that you could then maybe localize your variables.
Again, maybe how you are doing it is required by postgres, but if you
had a situation where you had multiple "swish_results" open and you
abort when reading a specific result, then you would only really want
to free the parent swish_results for that given result.
> Ouch. Another thing to fix. Am I correct to assume that this problem could
> be exposed by two swish-e queries running in parallel from different
> PostgreSQL back-ends (but only if they are threads?)
I don't know. Looks like swish_handle, swish_results, etc. are
global. So you couldn't have one query run at the same time as
another in the same process.
With respect to SwishResultPropertyStr() if two different threads use
the same swish_results object then there could be a problem since the
strings are stored in there.
Unsubscribe from or help with the swish-e list:
Help with Swish-e:
Received on Sun Mar 6 15:11:33 2005