On Sun, 2006-02-19 at 01:16 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Following patch implements matching sort cost calculations in the
planner in sort_cost()
As given, this didn't even compile. Cleaned up and applied.
Well given it was a patch-on-patch, I guess I did
On Thu, 2006-02-16 at 15:09 -0500, Robert Treat wrote:
On Thursday 16 February 2006 00:27, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
As stated, the following patch adds a list of patch submission guidelines
based on Simon Riggs suggestions to the developers FAQ.
A couple
Dmitry Karasik wrote:
[patch snipped]
I have cleaned this patch somewhat by removing some bitrot that occurred
since it was submitted, and adjusting formatting to something more
closely resembling postgresql style (please remember to follow our style
in future).
The attached works on
On Sun, 2006-02-12 at 20:15 +0300, Sergey E. Koposov wrote:
I'm proposing the fix of this bug:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00498.php
I think the suggested logic for compatible_tupdesc() is still wrong. For
example, the patch rejects the following:
create table usno
Small patch that makes ScanDirection a char(f|b|n) instead of a int or long or
whatever enum makes it. I tried to track down all the areas that depend on it
being specifically -1, 0, or 1. heapam appeared to be the biggest/only one.
(At least `gmake check` passed.)
--
Regards, James William Pye
On Sun, 2006-02-19 at 17:47 -0700, James William Pye wrote:
Small patch that makes ScanDirection a char(f|b|n) instead of a int or long or
whatever enum makes it.
Why?
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase your free
On Mon, 2006-02-06 at 16:05 -0600, P. Scott DeVos wrote:
I have been working with plpython for several months and have
been hampered by the lack of a traceback being logged when a
plpython function raises an error. I have written a patch causes
the PLy_traceback function to fully log the
On Sun, Feb 19, 2006 at 08:02:09PM -0500, Neil Conway wrote:
Why?
*Very* minor. one byte instead of four.
Yes, not really worth the time, but I was poking around at code anyways and
decided to write up a little patch.
--
Regards, James William Pye
---(end of
James William Pye wrote:
On Sun, Feb 19, 2006 at 08:02:09PM -0500, Neil Conway wrote:
Why?
*Very* minor. one byte instead of four.
Is one byte any faster anyway?
I would be expecting that with 64bit PC's a 64bit item is as fast, if
not faster than a 32bit, or 8 bit.
Yes, not really
On Sun, 2006-02-19 at 18:12 -0700, James William Pye wrote:
*Very* minor. one byte instead of four.
Arguably, enumerations are more readable than #defines and easier to
debug. Why do we care about saving 3 bytes for ScanDirection?
-Neil
---(end of
Attached is a patch that fixes three Python reference leaks in
PLy_traceback(): the objects returned by PyErr_Fetch() are owned by the
caller, so their reference count should be decremented. The memory leak
can be reproduced as follows:
create function import_fail() returns text as
'import
On Sun, Feb 19, 2006 at 08:21:31PM -0500, Neil Conway wrote:
Arguably, enumerations are more readable than #defines and easier to
debug.
Agreed. However, I didn't think it would impede much here as I figured gdb would
display 'f' or 'b' or 'n', dunno for sure tho as I didn't try.
Why do we
James William Pye [EMAIL PROTECTED] writes:
Small patch that makes ScanDirection a char(f|b|n) instead of a int or
long or whatever enum makes it.
Why is this a good idea? It strikes me as likely to break things,
without really buying anything.
regards, tom lane
On Sun, Feb 19, 2006 at 09:04:09PM -0500, Tom Lane wrote:
James William Pye [EMAIL PROTECTED] writes:
Small patch that makes ScanDirection a char(f|b|n) instead of a int or
long or whatever enum makes it.
Why is this a good idea?
A more appropriately sized variable for the data that it
James William Pye [EMAIL PROTECTED] writes:
In any case, some parts of the patch merely makes some code make use of the
sdir.h macros instead of depending on -1/0/1--heapam in particular. At least
those portions should be applied, no?
I can't see any great advantage there either ...
On Sun, 2006-02-19 at 19:46 -0700, James William Pye wrote:
In any case, some parts of the patch merely makes some code make use of the
sdir.h macros instead of depending on -1/0/1--heapam in particular. At least
those portions should be applied, no?
I agree: using the symbolic names for the
Title: Re: [PATCHES] WIP: further sorting speedup
Cool!
Well test this sometime soon and get back to you. Were kind of jammed this week, hopefully well get some time.
So you know, weve done some more work on the external sort to remove the tape abstraction from the code, which makes a
Luke Lonergan [EMAIL PROTECTED] writes:
So you know, we=B9ve done some more work on the external sort to remove the
=B3tape=B2 abstraction from the code, which makes a significant improvement.
Improvement where? That code's down in the noise so far as I can tell.
I see results like this (with
Title: Re: [PATCHES] WIP: further sorting speedup
The improvement was pre-Simons patch, and it came from implementing a single pass merge instead of a variable pass based on the number of tapes, as it is in Knuths tape algorithm. Also, the additional tricks in logtape.c were higher in the
Neil,I have written a patch causes the PLy_traceback function to fully log the traceback.The
output looks just like the traceback output provided by the python interpreter.Can any PL/Python folks comment on whether they want this patch?I am just a humble user of PL/Py, but tracebacks are very
On Sun, Feb 19, 2006 at 08:09:09PM -0500, Neil Conway wrote:
On Mon, 2006-02-06 at 16:05 -0600, P. Scott DeVos wrote:
I have been working with plpython for several months and have
been hampered by the lack of a traceback being logged when a
plpython function raises an error. I have written
21 matches
Mail list logo
