On Mon, 5 May 2008, Tom Lane wrote:
It bothers me a bit that the patch forces writes to be done all of file
A in order, then all of file B in order, etc. We don't know enough
about the disk layout of the files to be sure that that's good. (This
might also mean that whether there is a win is
Andreas 'ads' Scherbaum wrote:
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Not seen any gains from varying the WAL file size since then...
I think the use-case for varying the WAL segment size is unrelated to
performance of the master
On Mon, 5 May 2008 11:09:32 -0400 Alvaro Herrera wrote:
Andreas 'ads' Scherbaum wrote:
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Not seen any gains from varying the WAL file size since then...
I think the use-case for varying
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
I think the use-case for varying the WAL segment size is unrelated to
performance of the master server, but would instead be concerned with
adjusting the granularity of WAL log shipping.
Seems the
On Mon, 2008-05-05 at 13:06 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
I think the use-case for varying the WAL segment size is unrelated to
performance of the master server, but would instead be concerned with
Magnus Hagander wrote:
Hiroshi Saito wrote:
Anyway. If you get references to it, you need to pull in
port/dirmod.c into psql as well. Normally, it would get this
through libpgport, but it looks like your custom makfile is
pulling the files in directly instead. So adding dirmod to the
Tom Lane [EMAIL PROTECTED] writes:
The equivalent problem for views and functions is handled by restricting
CREATE OR REPLACE to not change the output column set of a view or the
type signature of a function, independently of whether there are any
actual references to the object. So maybe
