On Mon, 2007-09-24 at 21:26 -0500, Jaime Casanova wrote:
> On 9/24/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
> > > On 6/19/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > >
> > > > related TODO items:
> > > > - add a WAIT n clause in sa
On Tue, 2007-04-10 at 16:23 +0900, Koichi Suzuki wrote:
> Here're two patches for
>
> 1) lesslog_core.patch, patch for core, to set a mark to the log record
> to be removed in archiving,
>
> 2) lesslog_contrib.patch, patch for contrib/lesslog, pg_compresslog and
> pg_decompresslog,
>
> respec
On Tue, Sep 25, 2007 at 03:22:13PM +0900, ITAGAKI Takahiro wrote:
> Here is a WIP patch to make prepared statements thread-safe in ecpg.
> The variable prep_stmts was global but not protected by any locks.
> I divided it into per-connection field so that we can access prepared
> statements separate
Simon Riggs <[EMAIL PROTECTED]> writes:
> SQLServer and DB2 have more need of this than PostgreSQL, but we do
> still need it.
Why? What does it do that statement_timeout doesn't do better?
regards, tom lane
---(end of broadcast)--
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > SQLServer and DB2 have more need of this than PostgreSQL, but we do
> > still need it.
>
> Why? What does it do that statement_timeout doesn't do better?
If the execution time is negligible, then set
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > SQLServer and DB2 have more need of this than PostgreSQL, but we do
>> > still need it.
>>
>> Why? What does it do that statement_timeout doesn't do bett
This hook seems very strangely defined to me. Why did you not put the
hook at the point where the current geqo-vs-regular decision is made?
The reason is that I thought about gaining a control over the algorithm
used to solve individual subproblems in make_rel_from_joinlist. If we would
hav
Marshall, Steve wrote:
> I'm glad to see the patch making its way through the process. I'm also
> glad you guys do comprehensive testing before accepting it, since we are
> only able to test in a more limited range of environments.
>
> We have applied the patch to our 8.2.4 installations and are
Julius Stroffek <[EMAIL PROTECTED]> writes:
>> This hook seems very strangely defined to me. Why did you not put the
>> hook at the point where the current geqo-vs-regular decision is made?
>
> The reason is that I thought about gaining a control over the algorithm
> used to solve individual subpr
Well, It seems that I probably do not understand something quite well or
my explanation
is not clear. There is some example code of my idea in the attachment.
There is a function jos_search which has nearly the same code as
make_rel_from_joinlist.
The example tries geqo first and then the regul
Julius Stroffek <[EMAIL PROTECTED]> writes:
> Parts of the result path might be found by geqo and parts of it by
> regular algorithm.
Why would you care? Seems like forcing that to not happen is actively
making it stupider.
> If there is no way of how to make the code work then it makes no sens
On 9/25/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > SQLServer and DB2 have more need of this than PostgreSQL, but we do
> > > still need it.
> >
> > Why? What does it do that statement_timeout doe
Why would you care? Seems like forcing that to not happen is actively
making it stupider.
To better compare the algorithms and possibly not for final solution at
the beginning. If we would implement 10 algorithms and want to pickup
just 3 best ones to be used and throw 7 away.
Later on, we
I wrote:
> Awhile back, Chris Marcellino <[EMAIL PROTECTED]> wrote:
>> If this is in fact the case, I have a trivial patch to conditionally
>> enable SysV semaphores based on the OS release:
> I've tried this patch on my Mac laptop, and while it seems to work as
> advertised in terms of not eati
Julius Stroffek <[EMAIL PROTECTED]> writes:
>> Why would you care? Seems like forcing that to not happen is actively
>> making it stupider.
>>
> To better compare the algorithms and possibly not for final solution at
> the beginning. If we would implement 10 algorithms and want to pickup
> just 3
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
>> Why do you need to #undef EXEC_BACKEND, and is there a specific reason for
>> removing the include of win32.h?
> I put in in order to avoid -D of the Makefile.
If that matters, the problem is that somebody put the wrong stuff in the
wrong include fil
Hi.
From: "Tom Lane" <[EMAIL PROTECTED]>
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
Why do you need to #undef EXEC_BACKEND, and is there a specific reason for
removing the include of win32.h?
I put in in order to avoid -D of the Makefile.
If that matters, the problem is that somebody pu
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> From: "Tom Lane" <[EMAIL PROTECTED]>
>> Perhaps instead postgres_fe.h should #define FRONTEND?
> Yes, I feared that the physique of a main part broke. Then, Magnus said the
> same suggestion as you. It seems that it needs to be brushup.
> I am going
Hi.
From: "Tom Lane" <[EMAIL PROTECTED]>
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
From: "Tom Lane" <[EMAIL PROTECTED]>
Perhaps instead postgres_fe.h should #define FRONTEND?
Yes, I feared that the physique of a main part broke. Then, Magnus said the
same suggestion as you. It seems th
Here is a revised patch against CVS HEAD.
I fixed a bug in ECPGdeallocate_all().
Michael Meskes <[EMAIL PROTECTED]> wrote:
> Could you please create a small example that we could add to the
> regression suite?
The attached prep.pgc is an example for this fix,
that repeats EXEC SQL PREPARE and EX
Hello All,
We have prepared a patch (against CVS HEAD)for the TODO item:
* Hash
-During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Details of this patch's performance improvements can be found at
http://web
21 matches
Mail list logo
