On 23 Jun 2002, J. R. Nield wrote:
> So since we have all this buffering designed especially to meet our
> needs, and since the OS buffering is in the way, can someone explain to
> me why postgresql would ever open a file without the O_DSYNC flag if the
> platform supports it?
It's more code, if
On Sun, 2002-06-23 at 12:10, Curt Sampson wrote:
>
> So what we would really need to implement, if we wanted to be more
> efficient with trusted disk subsystems, would be the option of writing
> to the log only the changed row or changed part of the row, or writing
> the entire changed page. I do
On Sun, 2002-06-23 at 11:19, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > This should also allow us to disable completely the ping-pong writes
> > if we have a disk subsystem that we trust.
>
> If we have a disk subsystem we trust, we just disable fsync on the
> WAL and the per
On Sun, 23 Jun 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > This should also allow us to disable completely the ping-pong writes
> > if we have a disk subsystem that we trust.
>
> If we have a disk subsystem we trust, we just disable fsync on the
> WAL and the performance
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm looking at implementing IS DISTINCT FROM, among other things.
> ...
> I was thinking to implement this by simply expanding these rules within
> gram.y to be a tree of comparison tests.
Please, please, do not do that. Make a new expression node tr
Curt Sampson <[EMAIL PROTECTED]> writes:
> This should also allow us to disable completely the ping-pong writes
> if we have a disk subsystem that we trust.
If we have a disk subsystem we trust, we just disable fsync on the
WAL and the performance issue largely goes away.
I concur with Bruce: th
A couple of notes:
...
> Then, update *only* the ecpg source directory to the branch:
> cd pgsql/src/interfaces
> cvs update -r ecpg_big_bison ecpg
cvs will respect any changes you have made to the sources in your
directory and the changes will be preserved in the move to the branch.
Here is wh
> > I'm happy setting up the branch if that would be helpful. Let me know if
> > this is the way you want to proceed, and if so what you would like the
> That would be nice. I do not really knwo cvs myself.
Done. And here is how you would use it...
> > branch to be called.
> No idea. "new-bison"
On 23 Jun 2002, J. R. Nield wrote:
> On Sat, 2002-06-22 at 19:17, Bruce Momjian wrote:
> > J. R. Nield wrote:
> > > One other point:
> > >
> > > Page pre-image logging is fundamentally the same as what Jim Grey's
> > > book[1] would call "careful writes". I don't believe they should be in
> > > t
On Wed, Jun 19, 2002 at 06:23:24PM -0700, Thomas Lockhart wrote:
> Michael, is this acceptable to you? If you use remote cvs, then you
Yes, it is.
> I'm happy setting up the branch if that would be helpful. Let me know if
> this is the way you want to proceed, and if so what you would like the
On Sat, 2002-06-22 at 19:17, Bruce Momjian wrote:
> J. R. Nield wrote:
> > One other point:
> >
> > Page pre-image logging is fundamentally the same as what Jim Grey's
> > book[1] would call "careful writes". I don't believe they should be in
> > the XLOG, because we never need to keep the pre-im
On Sun, 23 Jun 2002, Christopher Kings-Lynne wrote:
> Hi All,
>
> Whereabouts in the code is the '*' expanded into the list of valid columns
See the rule 'target_el' in gram.y. The SelectStmt node is processed
further down the parser in analyze.c: see transformStmt(),
transformSelectStmt() and
Hi All,
Whereabouts in the code is the '*' expanded into
the list of valid columns and also where are the columns specified in the select
arguments (or whereever) checked for validity?
Chris
13 matches
Mail list logo
