On Sat, Dec 09, 2000 at 06:46:23PM -0500, Tom Lane wrote:
> I'm at a loss to see how a Pentium would arrive at a better result for
> MD5 than for CRC. For one thing, it's going to be at a disadvantage
> because it hasn't got enough registers. I'd be interested to see the
> assembly code...
Minu
On Sat, Dec 09, 2000 at 06:46:23PM -0500, Tom Lane wrote:
> Bruce Guenter <[EMAIL PROTECTED]> writes:
> > The difference is likely because PA-RISC (like most other RISC
> > architectures) lack a "roll" opcode that is very prevalent in the MD5
> > algorithm.
>
> A good theory, but unfortunately no
Hello,
I have quite strange problem. It's lsof -i -n -P
postmaste 20018 postgres6u IPv4 12241380 TCP
127.0.0.1:5432->127.0.0.1:6651 (CLOSE)
And there is no pair for it.
Backtrace of the backend shows:
(gdb) bt
#0 0x40198ba2 in recv () from /lib/libc.so.6
#1 0x80ab2c5 in pq_re
On Sat, Dec 09, 2000 at 01:58:29PM +1100, Horst Herb wrote:
> There have been some misconceptions in previous mails.
>
> 1.) A CRC is _not_ stronger than a hash. CRC is a subset of the hash domain,
> defined as "a fast error-check hash based on mod 2 polynomial operations"
> which has typically n
On Fri, Dec 08, 2000 at 10:17:00PM -0500, Tom Lane wrote:
> A couple further observations while playing with this benchmark ---
>
> 1. This MD5 implementation is not too robust. On my machine it dumps
> core if given a non-word-aligned data buffer. We could probably work
> around that, but it b
"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 WAL ?
It had better be possible under WAL, because vacuuming indexes is
done in ess
Bruce Guenter <[EMAIL PROTECTED]> writes:
>> This is a lot closer than I'd have expected, but it sure ain't
>> "MD5 40% faster" as you reported. I wonder why the difference
>> in results between your platform and mine?
> The difference is likely because PA-RISC (like most other RISC
> architectu
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Special handling of TOAST relations during VACUUM. TOAST relations
> >> are vacuumed while the lock on the master table is still active.
>
> > It seems very dangerous to m
Oleg Bartunov wrote:
>
> On Sat, 9 Dec 2000, Edmar Wiggers wrote:
>
> > Date: Sat, 9 Dec 2000 14:20:17 -0200
> > From: Edmar Wiggers <[EMAIL PROTECTED]>
> > To: mlw <[EMAIL PROTECTED]>, Oleg Bartunov <[EMAIL PROTECTED]>
> > Cc: Tom Lane <[EMAIL PROTECTED]>,
> > Hackers List <[EMAIL PROTECTED
> However, I have no objection to writing the value of DataDir into
> the socket lockfile (along with the owner's PID) if that seems like
> a worthwhile bit of info.
>
> Would there be any value in having a postmaster re-read its own socket
> lockfile every so often, to keep it looking active to
"Edmar Wiggers" <[EMAIL PROTECTED]> writes:
> One possible idea for SQL integration: can one use index access-method
> functions to query the FTS outside the database?
Hm. In principle an index access method can do whatever it darn
pleases. In practice, though, I think the main problem with mak
On Sat, 9 Dec 2000, Edmar Wiggers wrote:
> Date: Sat, 9 Dec 2000 14:20:17 -0200
> From: Edmar Wiggers <[EMAIL PROTECTED]>
> To: mlw <[EMAIL PROTECTED]>, Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: Tom Lane <[EMAIL PROTECTED]>,
> Hackers List <[EMAIL PROTECTED]>
> Subject: RE: [HACKERS] OK, does a
Personally, I'm not too afraid of having an FTS engine outside the database.
Oracle's Intermedia, which has a very powerful/fast FTS engine, uses that
approach.
I could look into how they do the SQL integration, maybe it would yeld some
ideas.
Mark, about that row identifier: OID's are no good f
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> Special handling of TOAST relations during VACUUM. TOAST relations
>> are vacuumed while the lock on the master table is still active.
> It seems very dangerous to me.
> When VACUUM of a master table was finished, the transaction is
> in already comm
On Sat, 9 Dec 2000, Tom Lane wrote:
> Date: Sat, 09 Dec 2000 10:45:33 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], Hackers List <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS]
>
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > btw, is t
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> btw, is there a restriction to length of key in GiST in 7.1 ?
Index tuples still have to fit in a block --- no TOAST table for
an index (yet).
I think we can compress index datums in-line though; at least that
should work in principle.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> There is no difference. If anything bad happens with the current
> >> multi-process server, all the postgres backends shutdown because the
> >> shared memory may be corrupted.
>
> > Yes. Are we adding reliability with per-process backends.
>
> Y
Oleg Bartunov wrote:
> postgres... It would be great.
>
> Gotcha. It's impossible to return a set from a function, so the only
> way to use perl to parse your bitmap. We did (in one project) external
> search using suffix arrays which incredibly fast and use postgres to
> return results to pe
On Sat, 9 Dec 2000, mlw wrote:
> Date: Sat, 09 Dec 2000 08:18:10 -0500
> From: mlw <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: Tom Lane <[EMAIL PROTECTED]>,
> Hackers List <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] OK, does anyone have any better ideas?
>
> Oleg Bartu
> -Original Message-
> From: Bruce Momjian
>
> I would like to mention that I met Tatsuo Ishii and Hiroshi Inoue while
> in Japan. This was the first time I met them, though I have worked with
> them on PostgreSQL for many years. Tatsuo is really the voice of
> PostgreSQL in Japan. It
> -Original Message-
> From: Jan Wieck
> Sent: Thursday, July 06, 2000 1:18 AM
> To: [EMAIL PROTECTED]
> Subject: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)
>
>
> Date: Wednesday, July 5, 2000 @ 12:17:41
> Author: wieck
>
> Update of /home/projects/pgsql/cvsroot/pgsq
Oleg Bartunov wrote:
>
> We need multi-key B-tree like index for such problem.
> Our full text search engine is based on arrays and we need to find quickly
> is some number exists in array - some kind of index over int array.
> We're currently testing GiST approach and seems will have some conclu
Here is a link to paper
"A new method to index and Query Sets" by J.Hoffman and J. Koehler
http://www.informatik.uni-freiburg.de/~hoffmann/publications.html
btw, is there a restriction to length of key in GiST in 7.1 ?
Regards,
Oleg
___
We need multi-key B-tree like index for such problem.
Our full text search engine is based on arrays and we need to find quickly
is some number exists in array - some kind of index over int array.
We're currently testing GiST approach and seems will have some conclusions
soon. I think multi-key B-
At 16:27 9/12/00 +0900, Tatsuo Ishii wrote:
>It might be interesting
>moving data/pg_xlog to a separate disk drive and see how it performs
>better.
Good idea. One of the fundamental rules with Dec/RDB is to put the
XLOG-equivant on a different drive from *any* database-related file.
Another setti
25 matches
Mail list logo