Neil,
thanks for your review. I accepted what you wrote for all items I don't
mention in this reply.
On Sat, Jan 07, 2006 at 10:59:27PM -0500, Neil Conway wrote:
+ #define COMPLETE_WITH_MALLOCED_LIST(list) \
+ do { COMPLETE_WITH_LIST((const char**) list); free(list); list
= (char**)
The following patch changes BgWriterCommLock to a spinlock. To confirm to
the spinlock coding rules(though not needed since we are in critical
section), rewrite the requests array into a circular one, which will
reduce the lock time when the bgwriter absorbs the requests. A
byproduct-benefit is
Qingqing Zhou [EMAIL PROTECTED] writes:
The following patch changes BgWriterCommLock to a spinlock.
Why is this a good idea?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Tom, all,
SELECT: currval
UPDATE: nextval, setval
USAGE: nextval, currval
+1.
--Josh
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Sun, 8 Jan 2006, Tom Lane wrote:
Why is this a good idea?
In spirit of incremental improvement:
(1) The spinlock itself are light weight than the LWLock here and we can
reduce the lock contention a little bit in AbsorbFsyncRequests();
(2) Don't need the CRITICAL SECTION in
Qingqing Zhou [EMAIL PROTECTED] writes:
On Sun, 8 Jan 2006, Tom Lane wrote:
Why is this a good idea?
In spirit of incremental improvement:
(1) The spinlock itself are light weight than the LWLock here and we can
reduce the lock contention a little bit in AbsorbFsyncRequests();
On Sun, 8 Jan 2006, Tom Lane wrote:
(1) The spinlock itself are light weight than the LWLock here and we
can reduce the lock contention a little bit in AbsorbFsyncRequests();
Spinlock-based coding is inherently much more fragile than LWLock-based
coding. I'm against changing things in
Qingqing Zhou [EMAIL PROTECTED] writes:
Yeah, only theoretically there is some marginal performance improvements.
Maybe you suggest we keep the LWLock but use the circular array part?
They're separable issues anyway.
Yeah, not related to lock. But I changed algorithm to circular array as
On Sun, 8 Jan 2006, Tom Lane wrote:
If you want the bgwriter to keep working in the face of an out-of-memory
condition in the hashtable, I think you'd have to change the coding so
that it takes requests one at a time from the queue.
Patched version will issue ERROR instead of PANIC at this
Qingqing Zhou [EMAIL PROTECTED] writes:
Do you suggest it makes sense that we continue to work on the patch or let
it be?
I don't see any problem here that urgently needs solving. If we ever
see any reports of out-of-memory failures in the bgwriter, then it'll
be time to worry about this, but
On Sun, 8 Jan 2006, Tom Lane wrote:
I don't see any problem here that urgently needs solving. If we ever
see any reports of out-of-memory failures in the bgwriter, then it'll
be time to worry about this, but I think it quite unlikely that we
ever will. (Even if we do, a simpler answer
Attached is a patch that makes the following changes:
(1) refactor execQual.c to expose a function for checking an instance of
a domain value against a list of domain constraints
(2) adjust pl/pgsql to fetch the constraints associated with the
function's return value. Because this is expensive,
Neil Conway [EMAIL PROTECTED] writes:
(2) adjust pl/pgsql to fetch the constraints associated with the
function's return value. Because this is expensive, the constraints are
fetched once per session, when the function is compiled.
We have gone out of our way to make sure that domain
13 matches
Mail list logo
