I've committed (most of?) the changes to implement a timestamp without
time zone type. To help with backward compatibility and upgrading, I've
made the *default* timestamp the one with time zone. That is, if you
want a timestamp without time zone you will have to fully specify it
verbatim. SQL99 c
> The O_DIRECT flag has been added in FreeBSD 4.4 (386 & Alpha) also. From
> the release notes:
>
> Kernel Changes
>
> The O_DIRECT flag has been added to open(2) and fcntl(2). Specifying this
> flag for open files will attempt to minimize the cache effects of reading
> and writing.
I wonder i
> pgbench unfortunately seems quite irrelevant to this issue, since it
> performs no textual operations whatsoever.
Yup.
> It'd be interesting to
> modify pgbench so that it updates the "filler" column somehow on each
> update (perhaps store a text copy of the new balance there), and then
> rep
Please apply attached patch to current CVS tree.
Changes:
1. gist__int_ops is now without lossy
2. added sort entry in picksplit
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg
>
> Sounds cool to me ... definitely something to fix before v7.2, if its as
> "easy" as you make it sound ... I'm expecting the new drive to be
> installed today (if all goes well ... Thomas still has his date/time stuff
> to finish off, now that CVSup is fixed ...
>
> Let''s try and target Mon
Hi noel,
The correct CVSROOT is now:
export CVSROOT=:pserver:[EMAIL PROTECTED]:/projects/cvsroot
And the password is blank or 'postgresql'
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, 21 September 200
Can someone else run this and confirm the results against the tip
of the CVS repository?
I'm trying to trace this bug (help welcome too).
(it was hidden in a trigger and a pain to narrow to this point)
-Brad
-
drop function mul1(int4,int4);
drop function mul2(int4,int4);
drop function call
> I'm using the current CVS (4.0.8-dev)- It's spectacular. Lower memory
> usage, more descriptive debug, better control over it. Tons more options,
> smaller code, much much faster.
>
> Can you trust it- sure. It isn't a release candidate. It is the
> current development version. As they
> [EMAIL PROTECTED] (Karthik Guruswamy) writes:
> > Anyone tried fragmenting tables into multiple sub tables
> > transparently through Postgres rewrite rules ? I'm having
> > a table with 200,000 rows with varchar columns and noticed
> > that updates,inserts take a lot longer time compared to a
FYI, I have added a number of these emails to the 'thread' TODO.detail list.
> On Wed, 26 Sep 2001, D. Hageman wrote:
>
> > > > Save for the fact that the kernel can switch between threads faster then
> > > > it can switch processes considering threads share the same address space,
> > > > st
> > Hi all,
> > By mapping the WAL files by each backend in to its address
> > space using "mmap" system call , there will be big
> > improvements in performance from the following point of view:
> > 1. Each backend directly writes in to the address
> > space
> We have been doing some scalability testing just recently here at Red
> Hat. The machine I was using was a 4-way 550 MHz Xeon SMP machine, I
> also ran the machine in uniprocessor mode to make some comparisons. All
> runs were made on Red Hat Linux running 2.4.x series kernels. I've
> examined a
> Save for the fact that the kernel can switch between threads faster then
> it can switch processes considering threads share the same address space,
> stack, code, etc. If need be sharing the data between threads is much
> easier then sharing between processes.
Just a clarification but bec
OK, I think we are on track for Monday beta. Marc, will you be
packaging a beta1 tarball on Monday or waiting a few days? I need to
run pgindent and pgjindent either right before or after beta starts.
Also, what are we doing with the toplevel /ChangeLogs. I never
understood the purpose of it,
I have just noticed a flaw in the handling of "-o backend-options"
postmaster parameters. To wit: although these options will be passed
to all backends launched by the postmaster, they aren't passed to
checkpoint, xlog startup, and xlog shutdown subprocesses (everything
that goes through Bootstra
> Bruce Momjian wrote:
> >
> > > Save for the fact that the kernel can switch between threads faster then
> > > it can switch processes considering threads share the same address space,
> > > stack, code, etc. If need be sharing the data between threads is much
> > > easier then sharing between
At 10:02 AM 9/27/01 -0400, mlw wrote:
>"D. Hageman" wrote:
>> I agree with everything you wrote above except for the first line. My
>> only comment is that process boundaries are only *truely* a powerful
>> barrier if the processes are different pieces of code and are not
>> dependent on each oth
Lincoln Yeoh wrote:
>
> At 10:02 AM 9/27/01 -0400, mlw wrote:
> >"D. Hageman" wrote:
> >> I agree with everything you wrote above except for the first line. My
> >> only comment is that process boundaries are only *truely* a powerful
> >> barrier if the processes are different pieces of code and
Bruce Momjian wrote:
>
> > Save for the fact that the kernel can switch between threads faster then
> > it can switch processes considering threads share the same address space,
> > stack, code, etc. If need be sharing the data between threads is much
> > easier then sharing between processes.
>
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> > > > Save for the fact that the kernel can switch between threads faster then
> > > > it can switch processes considering threads share the same address space,
> > > > stack, code, etc. If need be sharing the data between threads is much
>
20 matches
Mail list logo
