Re: [HACKERS] Re: CRC

2000-12-09 Thread Nathan Myers
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

Re: [HACKERS] Re: CRC

2000-12-09 Thread Bruce Guenter
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

[HACKERS] Strange behavior of PostgreSQL on Linux

2000-12-09 Thread Denis Perchine
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

Re: [HACKERS] CRC, hash & Co.

2000-12-09 Thread Bruce Guenter
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

Re: [HACKERS] Re: CRC

2000-12-09 Thread Bruce Guenter
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

[HACKERS] Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)

2000-12-09 Thread Tom Lane
"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

Re: [HACKERS] Re: CRC

2000-12-09 Thread Tom Lane
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

[HACKERS] RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)

2000-12-09 Thread Hiroshi Inoue
> -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

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread mlw
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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-12-09 Thread Bruce Momjian
> 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

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread Tom Lane
"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

RE: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread Oleg Bartunov
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

RE: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread Edmar Wiggers
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

[HACKERS] Re: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)

2000-12-09 Thread Tom Lane
"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

Re: [HACKERS]

2000-12-09 Thread Oleg Bartunov
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

Re: [HACKERS]

2000-12-09 Thread Tom Lane
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.

Re: [HACKERS] Using Threads?

2000-12-09 Thread Bruce Momjian
> 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

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread mlw
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

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread Oleg Bartunov
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

[GENERAL] RE: [HACKERS] Japan pictures

2000-12-09 Thread Hiroshi Inoue
> -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

[HACKERS] RE: [COMMITTERS] pgsql/src/backend/commands (command.c vacuum.c)

2000-12-09 Thread Hiroshi Inoue
> -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

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread mlw
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

[HACKERS]

2000-12-09 Thread Oleg Bartunov
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 ___

Re: [HACKERS] OK, does anyone have any better ideas?

2000-12-09 Thread Oleg Bartunov
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-

Re: [HACKERS] 7.0.3(nofsync) vs 7.1

2000-12-09 Thread Philip Warner
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