Attached is a plpython_error_1.out file that will fix cuckoo.
Unfortunately, I couldn't figure out how to submit it as an actual
patch, so it's just a file attachment. It should go in
src/pl/plpython/expected.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your
Alon Goldshuv wrote:
I revisited my patch and removed the code duplications that were there, and
added support for CSV with buffered input, so CSV now runs faster too
(although it is not as optimized as the TEXT format parsing). So now
TEXT,CSV and BINARY are all parsed in CopyFrom(), like in
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the error message spelling
in the first place? Is this a Python version thing (and if so,
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the error message spelling
in the first place? Is
On Thu, 14 Jul 2005 17:22:18 -0700
Alon Goldshuv [EMAIL PROTECTED] wrote:
I revisited my patch and removed the code duplications that were there, and
added support for CSV with buffered input, so CSV now runs faster too
(although it is not as optimized as the TEXT format parsing). So now
On Tue, Jul 19, 2005 at 02:48:52PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but
platypus kept working.
Hmm ... if it's *not* a
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
On Tue, Jul 19, 2005 at 02:48:52PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the
On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote:
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
Does this machine have ldd or the equivalent? If so, can you compare
ldd /path/to/python and ldd /path/to/plpython.so?
Oddly, no, it doesn't seem to have ldd. And
Hi Mark,
I improved the data *parsing* capabilities of COPY, and didn't touch the
data conversion or data insertion parts of the code. The parsing improvement
will vary largely depending on the ratio of parsing -to- converting and
inserting.
Therefore, the speed increase really depends on the
Jim C. Nasby wrote:
And the buildfarm script seems
to clean everything up even in the pgsqlkeep directories; or at least I
couldn't find a plpython.so laying around.
Nothing should be removed. If you are using the experimental code I
recently gave you all bets are off, but under normal
Hi Alon,
Yeah, that helps. I just need to break up my scripts a little to just
load the data and not build indexes.
Is the following information good enough to give a guess about the data
I'm loading, if you don't mind? ;) Here's a link to my script to create
tables:
Mark,
Thanks for the info.
Yes, isolating indexes out of the picture is a good idea for this purpose.
I can't really give a guess to how fast the load rate should be. I don't
know how your system is configured, and all the hardware characteristics
(and even if I knew that info I may not be able
On Tue, Jul 19, 2005 at 02:42:07PM -0600, Michael Fuhr wrote:
On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote:
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
Does this machine have ldd or the equivalent? If so, can you compare
ldd /path/to/python and ldd
Mark,
You should definitely not be doing this sort of thing, I believe:
CREATE TABLE orders (
o_orderkey INTEGER,
o_custkey INTEGER,
o_orderstatus CHAR(1),
o_totalprice REAL,
o_orderDATE DATE,
o_orderpriority CHAR(15),
o_clerk CHAR(15),
Whoopsies, yeah good point about the PRIMARY KEY. I'll fix that.
Mark
On Tue, 19 Jul 2005 18:17:52 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Mark,
You should definitely not be doing this sort of thing, I believe:
CREATE TABLE orders (
o_orderkey INTEGER,
o_custkey
On Sun, 2005-04-24 at 02:28 -0400, Tom Lane wrote:
In the current code there is no such thing as a hard read-only behavior
--- for example we will try to update commit-status hint bits no matter
what. Allowing that to be turned off would be interesting for a number
of purposes, such as
On Tue, Jul 19, 2005 at 04:51:03PM -0500, Jim C. Nasby wrote:
Can you search the system for all files named libpython* and post
what you find?
[EMAIL PROTECTED]:42]~:11%locate libpython
/Applications/NeoOfficeJ.app/Contents/MacOS/libpython.dylib
On Sat, 2005-05-21 at 18:38 +0100, Simon Riggs wrote:
On Fri, 2005-05-20 at 23:16 -0400, Bruce Momjian wrote:
Any farther on this?
No, but it will be in by deadline.
I need to make first base with partitioning before I can do this. Hence
my (otherwise rude) ignoring of your sterling work
On Tue, Jul 19, 2005 at 06:06:00PM -0500, Jim C. Nasby wrote:
[EMAIL
PROTECTED]:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:41%otool
-L libplpython.0.0.so
libplpython.0.0.so:
/System/Library/Frameworks/Python.framework/Versions/2.3/Python
(compatibility version
Good points on all, another element in the performance expectations is the
ratio of CPU speed to I/O subsystem speed, as Alon had hinted earlier.
This patch substantially (500%) improves the efficiency of parsing in the
COPY path, which, on a 3GHz P4 desktop with a commodity disk drive
represents
Mark,
I've not seen CVS in detail. I begain this work against 8.0.1 and
continued thru 8.0.2 to 8.0.3. It was not a great work. The patch is
rather straightforward and I appreciate if you try to port against CVS.
Mark Wong wrote:
Hi,
I grabbed the patches to try, but I was wondering
Simon Riggs [EMAIL PROTECTED] writes:
Short patch enclosed to turn off writing of commit-status hint bits.
Doesn't this entirely destroy the ability to truncate clog, and
therefore the ability to survive XID wraparound?
It probably also breaks subxact and multixact logging, but I haven't
looked
I working on the 'date' interval patch, I found a bug in handling of
interval division and multiplication. Look at this:
test= select '4 months'::interval / 5;
?column?
---
1 mon -6 days
(1 row)
With the attached fix, it returns the right
23 matches
Mail list logo
