Hi,
Le mardi 18 décembre 2007, Ron Mayer a écrit :
Has anyone looked into sorting algorithms that could use
more than one CPU or core at a time?
[...]
PS: Yeah, I know multi-threading is a hot-button on these
lists; but sorting seems a relatively isolated of the code
and I'd wonder if it'd
On Mon, 17 Dec 2007, Merlin Moncure wrote:
On Dec 17, 2007 3:23 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Oleg Bartunov wrote:
On Mon, 17 Dec 2007, Magnus Hagander wrote:
just interested do we have a place where developers could post
their availability for contract work ?
For example,
On Mon, 2007-12-17 at 16:34 -0800, Ron Mayer wrote:
PS: Yeah, I know multi-threading is a hot-button on these
lists; but sorting seems a relatively isolated of the code
and I'd wonder if it'd be isolate-able enough that multiple
CPUs could be used there.
I'm not sure multi-threading is the
Decibel! [EMAIL PROTECTED] writes:
Also, has anyone looked into adding a class of system calls that would
actually tell us if the kernel issued physical IO? I find it hard to believe
that other RDBMSes wouldn't like to have that info...
Yeah, I think that's called DTrace
--
Gregory
Martijn van Oosterhout wrote:
On Mon, Dec 17, 2007 at 01:48:31PM +, Alvaro Herrera wrote:
Log Message:
---
Improve wording.
I'd suggest removing everything between the parentheses, or perhaps
something like: By tracking allocated memory rather than used memory
it removes
Thanks Tom,
that made it clear I made a mistake.
That's the way it's supposed to be --- the scantuple slot is for
scanning your subplan's output.
Browsing through the code I get the impression, that
- ecxt_scantuple is only used by Scan nodes (i.e. SeqScan, IndexScan,
SubqueryScan and
Hi All,
I am new to this mailing list and want to participate to the 8.3.0 beta program.
(Sorry to be late BTW)
My name is Sebastien FLAESCH and I am in charge of the database interfaces at
Four J's Development Tools.
Our product is a Informix 4gl compatible compiler / runtime system.
I
Sebastien FLAESCH wrote:
Hi All,
I am new to this mailing list and want to participate to the 8.3.0
beta program.
(Sorry to be late BTW)
My name is Sebastien FLAESCH and I am in charge of the database
interfaces at Four J's Development Tools.
Our product is a Informix 4gl compatible
2007/12/16, Tom Lane [EMAIL PROTECTED]:
Hannu Krosing [EMAIL PROTECTED] writes:
But can't we _define_ such a subset, where we can do a transactionless
load ?
Sure ... but you'll find that it's not large enough to be useful.
Once you remove all the interesting consistency checks such as
Sorry I should have double checked, it's my fault.
I do not CLOSE the cursor before the third PQexecPrepare()...
Never mind.
Seb
Sebastien FLAESCH wrote:
Hi All,
I am new to this mailing list and want to participate to the 8.3.0 beta
program.
(Sorry to be late BTW)
My name is Sebastien
On Tue, Dec 18, 2007 at 09:32:51AM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Mon, Dec 17, 2007 at 01:48:31PM +, Alvaro Herrera wrote:
Log Message:
---
Improve wording.
I agree that the parenthised phrase should be removed.
Just realised I posted this to the wrong address last time...
I've been playing around with the new integrated tsearch2 stuff, and it
all seems to work just fine.
However, if you define an external dictionary file (in my case a list of
half-a-dozen stopwords) then obviously pg_dump can't
PQlookupOid(PGconn *conn, char **type_names, Oid *oids, int count);
We are backing away from this (not such a great idea). We are actually
working hard at removing Oid dependencies from our PGparam idea. We
think it is more generic to make the server allow InvalidOid for
composites and
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much.
Other than the ability to detect errors before the code goes off
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Dec 18, 2007 at 02:48:23PM +0100, [EMAIL PROTECTED] wrote:
But then, I still don't get the relationship between
INNER, OUTER varnos on the one side and
ecxt_scantuple, ecxt_outertuple and ecxt_innertuple on the other side.
May a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Dec 2007 12:09:28 +0300 (MSK)
Oleg Bartunov [EMAIL PROTECTED] wrote:
Our situation is different, we have involved into many
postgres-related projects, some of them rather popular and we have
permanent pressure from users to improve,
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
I have currently completed the following
a) If there are only trailing nulls in the heap, no null-bitmap gets stored
b) If there are trailing nulls in addition to nulls inbetween values in the
heap, then the trailing nulls are not added to
KaiGai Kohei wrote:
I found a tiny fix for configure.in at Nov 26.
http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
It seems to me this check enforces us to use autoconf 2.59, not the latest
one.
Is there any reason for this change?
For example,
Andrew Dunstan wrote:
KaiGai Kohei wrote:
I found a tiny fix for configure.in at Nov 26.
http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
It seems to me this check enforces us to use autoconf 2.59, not the latest
one.
Is there any reason for this
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
I found a tiny fix for configure.in at Nov 26.
http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
It seems to me this check enforces us to use autoconf 2.59, not the latest
one.
Decibel! [EMAIL PROTECTED] writes:
When a read() call returns, surely the kernel knows whether it actually
issued
a physical read request to satisfy that. I don't see any reason why you
couldn't have a version of read() that returns that information. I also
rather
doubt that we're the
On Wed, 19 Dec 2007, KaiGai Kohei wrote:
It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?
2.59 is the stable version of autoconf PostgreSQL 8.3 is built against,
and the check keeps anyone from accidentally running it
Andrew, Greg, Thanks for your infomation.
I've skimed through the thread.
It seems to me that using autoconf-2.59 and applying a patch to pre-built
configure is the most appropriate way to add an original configure option.
Thanks,
Greg Smith wrote:
On Wed, 19 Dec 2007, KaiGai Kohei wrote:
It
Greg Smith [EMAIL PROTECTED] writes:
On Wed, 19 Dec 2007, KaiGai Kohei wrote:
It seems to me this check enforces us to use autoconf 2.59, not the latest
one.
Is there any reason for this change?
The brutally long thread at
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00706.php
Hi,
Does anybody have an information about GiST index benchmark? I'm
planning to run GiST benchmark and analyze WAL structure to see PG's
dynamic behavior.
Regards;
--
Koichi Suzuki
---(end of broadcast)---
TIP 3: Have you checked our
25 matches
Mail list logo
