Can some one tell me what are the changes that i have to do , if i want the
inner scan node of a nested loop join to start the scaning from thepoint
where it had left previously .
As of now the scan for the inner relation re-starts for a change in the
correlation value from the outer relation.
--On Sunday, February 22, 2004 23:00:31 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I wasn't able to test on HP-UX
I get the same result on HPUX, after whacking the test program around
a bit: no change in the number of files we can open. Confirmations on
tues evening euro time is fine with me. I am at GMT-5 so it will be
afternoon for me. What time ?
We should attempt an agenda?
Dave
On Sun, 2004-02-22 at 15:33, HORNYAK Laszlo wrote:
Hi all!
Sorry for my latencies.
An IRC chat is ok for me, anytime.
On Sun, Feb 22, 2004 at 08:08:00PM
I wrote:
Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains the bad
file number error I was getting on AIX, too...
And sure
On Slackware 8.1:
[EMAIL PROTECTED]:~/src$ ./eatallfds libm.so libtcl.so libjpeg.so
dup() failed: Too many open files
Was able to use 1021 file descriptors
dup() failed: Too many open files
Was able to use 1021 file descriptors after opening 3 shared libs
On OpenBSD 3.1:
grayling# ./eatallfds
--On Monday, February 23, 2004 04:52:09 -0800 Kevin Brown
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
I feel like a moron, having missed that. Probably explains
Hello,
Can some one tell me what and when (Plan*)()-chgParam will contain ?? One
of the comments mentions that it contains the list of changed ones from
outer.. can some be more eloborate .. ( if possible with a eg )
Thanks,
Ramu
On Sunday 22 February 2004 05:57 pm, Gaetano Mendola wrote:
Do you think that we'll have too a RPM binary distribution for the 7.3.6
( the 7.3.5 don't have it yet ) ?
Yes. I apologize for the lag; my wife miscarried and that has thrown my free
time for a loop as I help her and my other four
Hi all,
I was just going thr. the ecpg sources checking for thread safety.
It looks like the mutex protects the connections list in connection.c. I do
not like that from a application developers perspective.
If I am developing an application and using multiple connections in multiple
Thomas Hallgren wrote:
1. Select Pl/Java_JNI.
2. Select Pl/Java_remote
3. Choose both and agree on the SQL + Java semantics
4. Make the postmaster spawn threads rather than processes
(controversial? Nah :-) )
Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
and most
Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
and most lightweight solution, but perhaps not the most featureful.
GCJ is definitely an alternative for the reasons you mention. I didn't
mention it (nor any other JVM) because I see it as one of several JVM's
that Pl/Java
Bruce Momjian [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Hmmm I'm not sure how you arrived at this wording for the TODO. How are
we defining a syntax error?
Parser error, I would say. Misspelling a table name, perhaps.
FWIW, a misspelled table name is plainly a semantic error, not
http://developer.osdl.org/markw/ia64/dbt2/
I have a summary of intial results from our DBT-2 workload with
PostgreSQL 7.4.1 on a 4-way Itanium2 system with 16GB of memory and 56
drives using LVM2 and linux-2.6.3. There's readprofile
and oprofile data, but oprofile is seg faulting when it's
I noticed while doing some debugging this morning that if the postmaster
crashes for some reason (eg kill -9) the bgwriter process never goes
away. Backends will eventually exit when their clients quit, and the
stats collection processes shut down nicely, but the bgwriter process
has to be killed
Kind people,
I bumped across this several times, and am wondering what SQL99 and
SQL200x have to say about column numbers or aliases in HAVING. SQL92
is fairly clear (no) but also somewhat out of date.
Here's a scenario:
SELECT foo_name, count(*) as foo_count
FROM foo
GROUP BY foo_name
HAVING
For me it would be fine at 7pm GMT Tuesday. Here's an attempted agenda:
1. Try to identify the common public interface (SQL and Java).
This is the most important item in my view since it enables a user to
seamlessly switch between our two solutions. You describe your design from
this angle, and I
Hello all,
3. Probe deeper and see if there's more that we can share (C-code
essentially).
I have my doubts about sharing C-code since we do things fundamentally
different. I know you have a generic call mechanism that we could use to
establish a common ground, but I think it would bad for
On Mon, Feb 23, 2004 at 06:36:48PM -0500, Tom Lane wrote:
[EMAIL PROTECTED] (David Fetter) writes:
I bumped across this several times, and am wondering what SQL99
and SQL200x have to say about column numbers or aliases in HAVING.
SQL99 not only does not allow them in GROUP BY or HAVING,
David Fetter [EMAIL PROTECTED] writes:
Just in general, isn't it better to write a piece of code (here, a
possibly-complicated aggregate) just once and refer to it elsewhere
rather than have to write a separate copy of it everywhere it's used?
In general, you do that with subselects. Having
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
Could I suggest that your next step is to sync up with the work
being
done on tuning the DBT-3 query workload? As I'm sure you're aware,
that
is very similar to TPC-H workload, where most of the commercial
RDBMS
vendors utilise Materialized
Kevin Brown [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, it seems that the real problem here is that we are so far off
base about how many files we can open. I wonder whether we should stop
relying on sysconf() and instead try to make some direct probe of the
number of files we can
Simon Riggs [EMAIL PROTECTED] writes:
You are 100% right: MVs are unambiguously not allowed as part of the
TPC-H spec - what 1.5.7 shows is how useful MVs are: they've had to ban
them!
Ah, now I get your point. You're quite right, the TPC-H queries taken
as a repetitive workload would be a
Hi,
I've just talked to a few users on IRC who cannot restore dumps because
they use user-defined functions in CHECK constraints.
Any chance this will be fixed using dependencies? Or maybe it's just
easy to put all ADD CHECKs at the very end?
Chris
---(end of
Tom Lane wrote:
I noticed while doing some debugging this morning that if the postmaster
crashes for some reason (eg kill -9) the bgwriter process never goes
away. Backends will eventually exit when their clients quit, and the
stats collection processes shut down nicely, but the bgwriter process
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So it can keep
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I've just talked to a few users on IRC who cannot restore dumps because
they use user-defined functions in CHECK constraints.
Any chance this will be fixed using dependencies?
It's done in CVS tip.
If you were brave you could use CVS-tip
On the re-use front it would be VERY nice if you could
somehow have a single patch for PostgreSQL's C code that called a set of
Java interfaces. Then each of your implementations could implement that
set
of Java interfaces (one using JNI, the other using RMI). This would allow
the user to
27 matches
Mail list logo