On Jan 27, 2004, at 6:25 PM, Tom Lane wrote:
Perhaps more to the point: all this is predicated on an assumption no
longer particularly valid, which is that the kernel's ideas about disk
write scheduling matter at all. A decent SCSI disk drive will pre-empt
the kernel's ideas anyway by absorbing as
Jan Wieck <[EMAIL PROTECTED]> writes:
> Now doing fsync() or fdatasync() of possibly dozens of files in a row,
> forcing the kernel to do one scattered file after another, letting the
> disk heads dance like step-chicken on a hot tin ... that will be an
> improvement, oh boy.
I'm not convinced
Bruce Momjian wrote:
I guess my major problem with moving away from sync is similar to the
reason we don't do raw devices --- sync is best done in the kernel and
disk driver that knows more about how to do it efficiently. I haven't
see any non-sync solution with performance similar to sync(). Ho
CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/01/27 20:05:04
Modified files:
src/backend/optimizer/util: clauses.c
Log message:
simplify_function() mustn't try to evaluate functions that return
composite types, because Tu
CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/01/27 20:05:26
Modified files:
src/backend/optimizer/util: Tag: REL7_4_STABLE clauses.c
Log message:
simplify_function() mustn't try to evaluate functions that return
composit
CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/01/27 12:51:43
Modified files:
doc/src/sgml : runtime.sgml
Log message:
Improve the documentation of the 'join_collapse_limit' GUC var. Thanks to
Tom Lane for some editorial
