On Sep 5, 2008, at 9:43 PM, Bruce Momjian wrote:
Fortunately there's an easy fix for that. If we optimize
RecordAndGetPageWithFreeSpace so that it will always return the next
page if it has enough space, we'll be doing sequential I/O again.
That's
trivial as long as the next heap page is on
On Sep 5, 2008, at 9:06 AM, D'Arcy J.M. Cain wrote:
...etc. Would it be OK if I went in and added .cvsignore files to
keep
the noise level down? I guess I could have my daily script filter
them
out but there may be times when there really is an unexpected file and
I want to follow up on
Decibel! wrote:
On Sep 5, 2008, at 9:43 PM, Bruce Momjian wrote:
One other thing to keep in mind is that VACUUM can reduce a table's size
if the trailing blocks are empty, so there is some gain if the earlier
parts of the table are preferred for inserts.
Yeah; I would actually really, really
MUHAMMAD ASIF wrote:
During the integration of pldebugger (
http://pgfoundry.org/projects/edb-debugger ) with postgres on windows I faced
a problem that plugins are not being copied to the lib/plugins directory.
Plugins should be copied in (Installation dir)lib/plugins to work properly.
To
Simon Riggs wrote:
On Tue, 2008-09-02 at 11:39 -0400, Tom Lane wrote:
, I'm not seeing the use-case
for an rmgr that only executes during recovery; in fact I'm not entirely
sure that I see a use-case for this entire patch. Where are the WAL
records that the loadable rmgr processes going to
Heikki Linnakangas wrote:
BTW, we haven't talked about how to acquire a snapshot in the slave.
You'll somehow need to know which transactions have not yet
committed, but will in the future. In the master, we keep track of
in-progress transaction in the ProcArray, so I suppose we'll need to
do
On Fri, Sep 12, 2008 at 07:27:55PM -0500, Decibel! wrote:
On Sep 5, 2008, at 9:06 AM, D'Arcy J.M. Cain wrote:
...etc. Would it be OK if I went in and added .cvsignore files to
keep the noise level down? I guess I could have my daily script
filter them out but there may be times when there
I'm getting these on Fedora-9:
tqual.c:115: warning: inlining failed in call to ‘SetHintBits’: call is
unlikely and code size would grow
tqual.c:377: warning: called from here
tuplesort.c: In function ‘comparetup_index’:
tuplesort.c:2423: warning: inlining failed in call to ‘myFunctionCall2’:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes:
I'm getting these on Fedora-9:
tqual.c:115: warning: inlining failed in call to âSetHintBitsâ: call is
They're just cosmetic. We don't generally worry about fixing cosmetic
warnings in back branches.
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
interval ... sql_standard...iso_8601...
backward_compatible ...depends... on ... DateStyle...
...How about decoupling interval_out's behavior
from DateStyle altogether, and instead providing values of IntervalStyle
that match all the
10 matches
Mail list logo
