Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Why not? The intermediate state *is valid*. We just haven't
> >> removed no-longer-referenced index and TOAST entries yet.
>
> > Do you mean *already committed* state has no problem and
> > VACUUM is always p
[ Charset ISO-8859-1 unsupported, converting... ]
> I've run tests (with 50 .. 250 simult users) for some PG project
> of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
> 3 times slower than 7.0.3 (nofsync). It was not the best day in
> my life - WAL looked like big bottleneck -:(
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > I'd like to see a timestamp for when the image was created, and a
> > 128-byte comment field to allow annotations, even after the fact.
>
> Both seem like reasonable options. If you don't mind, however,
> I'd suggest that they be left for inclusion
[EMAIL PROTECTED] (Nathan Myers) writes:
> I'd like to see a timestamp for when the image was created, and a
> 128-byte comment field to allow annotations, even after the fact.
Both seem like reasonable options. If you don't mind, however,
I'd suggest that they be left for inclusion as chunks i
OK, I am through mail email backlog from my Japan visit. I will work on
a full 7.1 changes list this week.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Ch
On Sun, Dec 10, 2000 at 04:08:58PM -0800, Nathan Myers wrote:
> On Thu, Dec 07, 2000 at 02:28:28PM -0500, Tom Lane wrote:
> > Given all that, here is a proposed spec for the header:
> > ...
> > Comments?
>
> (I have also suggested, in private mail, that the "header length"
> field should be the
> I appreciate your comments and would like to respond to your concerns.
> The API I sketched in my earlier e-mail is borrowed heavily from
> Rogue Wave's dbtools.h++ library. I think it can be a very clean and
> elegant way of accessing a database.
Rogue Wave's API is quite interesting. It wou
> Also, IIRC part of the problem with text-based COPY is that we can't
> specify field order (I think this affectes dumping the regression DB).
> Would it be possible to add the ability to (a) specify field order, and (b)
> dump a subset of fields?
Informix does this nicely:
UNLOAD TO "f
On Thu, Dec 07, 2000 at 02:28:28PM -0500, Tom Lane wrote:
> Given all that, here is a proposed spec for the header:
> ...
> Comments?
I've been thinking about this.
I'd like to see a timestamp for when the image was created, and a
128-byte comment field to allow annotations, even after the f
> I will not complain about sticking a "version 1.0" field into a format
> when there is no real intention of changing it in the future ... but
> assigning deep significance to major/minor numbers, or something like
I assume the version would be the COPY format version, not the
PostgreSQL version
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? The intermediate state *is valid*. We just haven't
>> removed no-longer-referenced index and TOAST entries yet.
> Do you mean *already committed* state has no problem and
> VACUUM is always possible in the state ?
Yes.
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > There's no command other than VACUUM which continues to
> > access table/index after *commit*. We couldn't process
> > significant procedures in such an already commiitted state,
> > could we ?
>
> Why not? The intermediate st
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, guess I can delete this email now? :-)
Yes, it's done.
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
Its handling of nulls is bizarre, too. I'm thinking this might be a
good time to abandon backwards compatibility and switch to a format
that's a little easier to read and write. Does anyone have an opinion
pro or con about that?
>>
>
I will work on a list this week. It will have the same format as usual,
if that is OK.
> > I browsed through the CVS logs and made this list of the important
> > stuff. There's a ton of less important stuff...
>
> Shall we consider this the start of the list then? I think there may be
> a coup
On Sun, Dec 10, 2000 at 02:53:43PM -0500, Tom Lane wrote:
> > On my Celeron, the timing for those six opcodes is almost whopping 13
> > cycles per byte. Obviously there's some major performance hit to do the
> > memory instructions, because there's no more than 4 cycles worth of
> > dependant ins
Barry Lind writes:
> The reason for this is that in the en_US locale all non-alphanumeric
> characters are ignored when doing string comparisons. So the data above
> gets treated as:
> abc.xyz = abcxyz = abc/xyz (as the non-alphanumeric characters of '.'
> and '/' are ignored). This implys tha
This is the last post I will make about my text search system, I'll
respond off line if anyone wants to correspond. I have taken up too much
bandwidth as it is. The only reason I have been so persistent is that I
can't believe that I am the only person having this particular problem,
and that some
On Sun, Dec 10, 2000 at 12:24:59PM -0800, Alfred Perlstein wrote:
> I would try unrolling the loop some (if possible) and retesting.
The inner loop was already unrolled, but was only processing single
bytes at a time. By loading in 32-bit words at once, it reduced the
cost to only 7 cycles per b
> > Its handling of nulls is bizarre, too. I'm thinking this might be a
> > good time to abandon backwards compatibility and switch to a format
> > that's a little easier to read and write. Does anyone have an opinion
> > pro or con about that?
>
> BINARY COPY scared the bejeezus out of me, any
* Tom Lane <[EMAIL PROTECTED]> [001210 12:00] wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> >> A good theory, but unfortunately not a correct theory. PA-RISC can do a
> >> circular shift in one cycle using the "shift right double" instruction,
>
> > Interesting. I was under the impressio
Tom, guess I can delete this email now? :-)
>
> I start detail study of PG's memory management (because, I want remove
> prepared query-cache to shmem (more is in my old discussion with Jan)).
>
> I see current code in the aset.c and I found small non-effective memory
> usage.
>
>
> Des
[EMAIL PROTECTED] (Nathan Myers) writes:
> Minutiae aside, it's clear that the MD5 and CRC are "comparable",
> regardless of CPU.
We've established that the inner loops are pretty comparable. I'm
still concerned about the startup/termination costs of MD5 on short
records. The numbers Bruce and
Bruce Guenter <[EMAIL PROTECTED]> writes:
>> A good theory, but unfortunately not a correct theory. PA-RISC can do a
>> circular shift in one cycle using the "shift right double" instruction,
> Interesting. I was under the impression that virtually no RISC CPU had
> a rotate instruction. Do an
> Don Baccus <[EMAIL PROTECTED]> writes:
> > The optimizer should do a better job on your first query, sure, but why
> > don't you like writing joins?
>
> The join wouldn't give quite the same answers. If there are multiple
> rows in table2 matching a particular table1 row, then a join would giv
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Now that the executor understands about multiple join rules (for
>> OUTER JOIN support), I've been thinking about inventing a new join rule
>> that says "at most one output row per left-hand row" --- this'd be sort
>> of the opposite of the LEFT OUTER J
Thomas Lockhart writes:
> [valid reasons why docs are shipped in tar.gz format]
>
> Anyway, since we no longer put the docs tarball into cvs, then we could
> rethink the techniques. Peter, you seem to have done enough work on this
> to have an opinion, so what exactly would you prefer for packagi
Denis Perchine <[EMAIL PROTECTED]> writes:
> Looks like it tries to read on socket which is already closed from other
> side. And it seems like recv did not return in this case. Is this OK, or
> kernel bug?
Sounds like a kernel bug --- recv() should *always* return immediately
if the socket is
parse_coerce.c contains the following conversation --- I believe the
first XXX comment is from me and the second from you:
/*
* Still too many candidates? Try assigning types for the unknown
* columns.
*
* We do this by examining each unknown argument position to see if al
Bruce Momjian writes:
> Removing 10-day-old files from /tmp seems pretty broken to me, and I
> hate to code around broken stuff.
(It's not 10-day-old files, it's files that have not been used for 10
days.)
But both the Linux file system standard and POSIX 2 have requirements
and/or recommendati
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> There's no command other than VACUUM which continues to
> access table/index after *commit*. We couldn't process
> significant procedures in such an already commiitted state,
> could we ?
Why not? The intermediate state *is valid*. We just haven't
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Hmm,is there any good reason to vacuum toast table in the
> > transaction which was already internally committed by vacuum
> > of the master table ? Is it possible under W
Andrew Snow wrote:
>
> Could you perhaps post the code you have for splitting a text field up into
> keys, then I could work on turning into a new type of index with a new
> operator, as Tom suggested?
>
> (Or is this already what the text search code in contrib already does??)
I think that spl
33 matches
Mail list logo
