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 gues
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.
> >
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 HEAD
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
In
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 s
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 t
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 broadcast)
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 wor
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 broadcast)--
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 foosock
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 c
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 th
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!
We’ll test this sometime soon and get back to you. We’re kind of jammed this week, hopefully we’ll get some time.
So you know, we’ve done some more work on the external sort to remove the “tape” abstraction from the code, which makes a s
"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 (
Title: Re: [PATCHES] WIP: further sorting speedup
The improvement was pre-Simon’s 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 Knuth’s tape algorithm. Also, the additional tricks in logtape.c were higher in the pro
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 w
21 matches
Mail list logo