Yury Bokhoncovich wrote:
> Hello!
>
> On Sat, 5 Oct 2002, Bruce Momjian wrote:
>
> >
> > Yes, I agree with you Manfred, but more people _don't_ want it to
> > change, and like it the way it is, so we will just keep it and add
> > now("string").
>
> IMHO the best way could be GUC-default/SET se
Hello!
On Sat, 5 Oct 2002, Bruce Momjian wrote:
>
> Yes, I agree with you Manfred, but more people _don't_ want it to
> change, and like it the way it is, so we will just keep it and add
> now("string").
IMHO the best way could be GUC-default/SET session-based variable
controlling the behavio
Hello hackers,
I'm trying to get something from pg_filedump. However, the version
published in sources.redhat.com/rhdb doesn't grok a lot of changes in
current CVS. I changed all those and made it compile... but looks like
that's only the easy part. I get bogus values everywhere (block sizes,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What's the naming convention for new functions/variables? I've seen
> this_way() and ThisWay() used without visible distinction. I've used
> both in previously submitted and accepted patches...
> Does it matter?
Consistency? We don't need no steenki
Curt Sampson <[EMAIL PROTECTED]> writes:
> ... Avoiding cross-posting would be nice, since I am getting lots of
> duplicate messages these days.
Cross-posting is a fact of life, and in fact encouraged, on the pg
lists. I suggest adapting. Try sending
set all unique your-email-address
to
On Thu, 3 Oct 2002, Shridhar Daithankar wrote:
> Our major concern remains load time as data is generated in real time and is
> expecetd in database with in specified time period.
If your time period is long enough, you can do what I do, which is
to use partial indexes so that the portion of the
On Thu, 3 Oct 2002, Shridhar Daithankar wrote:
> Well, we were comparing ext3 v/s reiserfs. I don't remember the journalling
> mode of ext3 but we did a 10 GB write test. Besides converting the RAID to RAID-
> 0 from RAID-5 might have something to do about it.
That will have a massive, massive e
On Sun, 2002-10-06 at 19:35, Greg Copeland wrote:
> On Sun, 2002-10-06 at 18:07, Tom Lane wrote:
> >
> > CPU loading goes from 80% idle at 1 client to 50% idle at 5 clients
> > to <10% idle at 10 or more.
> >
> > So this does seem to be a nice win, and unless I hear objections
> > I will apply i
On Sun, 2002-10-06 at 18:07, Tom Lane wrote:
>
> CPU loading goes from 80% idle at 1 client to 50% idle at 5 clients
> to <10% idle at 10 or more.
>
> So this does seem to be a nice win, and unless I hear objections
> I will apply it ...
>
Wow Tom! That's wonderful! On the other hand, maybe
I said:
> There is a simple error
> in the current code that is easily corrected: in XLogFlush(), the
> wait to acquire WALWriteLock should occur before, not after, we try
> to acquire WALInsertLock and advance our local copy of the write
> request pointer. (To be exact, xlog.c lines 1255-1269 in
Hello hackers,
What's the naming convention for new functions/variables? I've seen
this_way() and ThisWay() used without visible distinction. I've used
both in previously submitted and accepted patches...
Does it matter?
--
Alvaro Herrera ()
"La libertad es como el dinero; el que no la sabe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think creating a new LWLockId (BTFreeListLock?) can help here. The
> operations on freelist are short lived and rather infrequent so it
> doesn't seem to matter that it is global to all indexes.
Seems like a really bad idea to me ... what makes you
On Sun, 2002-10-06 at 11:46, Tom Lane wrote:
> I can't personally get excited about something that only helps if your
> server is starved for RAM --- who runs servers that aren't fat on RAM
> anymore? But give it a shot if you like. Perhaps your analysis is
> pessimistic.
I do suspect my analys
On Sat, Oct 05, 2002 at 08:25:35PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>> It seems to me I'll have to add some amount of lock types
> >>> in the lock manager. Does that bother you?
> >>
> >> Such as?
>
> > There are three new lock modes: R, RX and RS (Reorgani
Greg Copeland <[EMAIL PROTECTED]> writes:
> I personally would at least like to see an aio implementation and would
> be willing to even help benchmark it to benchmark/validate any returns
> in performance. Surely if testing reflected a performance boost it
> would be considered for baseline incl
On Sat, 2002-10-05 at 14:46, Curtis Faith wrote:
>
> 2) aio_write vs. normal write.
>
> Since as you and others have pointed out aio_write and write are both
> asynchronous, the issue becomes one of whether or not the copies to the
> file system buffers happen synchronously or not.
Actually, I
On 26 Sep 2002, Neil Conway wrote:
> The fact that ext2 defaults to asynchronous mode and UFS (at least on
> the BSDs) defaults to synchronous mode seems like a total non-issue to
> me. Is there any more to the alleged difference in reliability?
It was sort of pointed out here, but perhaps not m
On Fri, 20 Sep 2002, Shridhar Daithankar wrote:
> On 20 Sep 2002 at 21:22, Shridhar Daithankar wrote:
>
> > Mysql takes 221 sec. v/s 1121 sec. for postgres. For postgresql,
> > that is around 11.5K rows per second. Each tuple has 23 fields with
> > fixed length of around 100 bytes
Yes, postgres
tom lane wrote:
> "Curtis Faith" <[EMAIL PROTECTED]> writes:
> > What about splitting out parsing, optimization and plan generation from
> > execution and having a separate pool of exececutor processes.
>
> > As an optimizer finished with a query plan it would initiate execution
> > by grabbing a
On Sun, 2002-10-06 at 04:03, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Or its solution ;) as instead of the predicting we just write all data
> > in log that is ready to be written. If we postpone writing, there will
> > be hickups when we suddenly discover that we need to wr
20 matches
Mail list logo
