On Sat, 1 Dec 2007, Jaime Casanova wrote:
i'm trying to compile postgres in winxp for the first time in order to
try recent Magnus patch discussed here
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01307.php
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:27: error:
rede
Hi,
i'm trying to compile postgres in winxp for the first time in order to
try recent Magnus patch discussed here
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01307.php
i've installed mingw, msys and msysDTK
i tried "./configure --without-zlib" and then "make install" and get this err
Sam Mason <[EMAIL PROTECTED]> writes:
> Sounds as though you need some sort of type inference algorithm. There
> are quite a few decidable ones around, the one by Hindley-Milner being
> very popular/common. Decidable means you get the correct answer out in
> a reasonable amount of time or it fail
On Fri, 30 Nov 2007, Kevin Grittner wrote:
checkpoint_segments = 50
Here's how I'm reading your data:
16:43:11 : Checkpoint start
16:44:23 : Checkpoint ends [ 1:22 long]
1:01 passes
16:45:24 : Checkpoint start
16:46:36 : checkpoint ends [1:22 long]
If you're getting a checkpoint every minute
On Nov 30, 2007 11:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > I disagree. For people who want a quick summary of the major
> user-facing
> > things changed we'll have multiple sources: (a) the announcement, (b)
> the
> > press features list, (c) the
>>> On Tue, Aug 21, 2007 at 1:12 PM, in message
<[EMAIL PROTECTED]>, Greg Smith
<[EMAIL PROTECTED]> wrote:
> My suggestion for a starting 8.3 configuration for you would be adjusting
> these settings as follows:
>
> shared_buffers=1GB
> checkpoint_segments = 50
I'm not into the most meaningfu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... I am
>> tempted to remove that from CCI and call it from just a selected few CCI
>> call sites, instead --- maybe only CommitTransactionCommand. OTOH this
>> step might reasonably be considered too risky for late beta, since it
>>
Tom Lane wrote:
> Once we have the knowledge of whether the current command ID is "dirty",
> we can skip everything inside CommandCounterIncrement when it is not;
> except for the AtStart_Cache() call, ie, AcceptInvalidationMessages().
> What that is looking for is asynchronous DDL-change notifica
On Nov 30, 2007 9:09 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm sorry to suggest anything at this point, but... would it be less invasive
> if instead of requiring the immediate cast you created a special case in the
> array code to allow a placeholder object for "empty array of unknown typ
I wrote:
OK, I have a fairly ugly manual workaround, that I don't yet
understand, but seems to work for me.
In your session, run the following code before you do anything else:
CREATE OR REPLACE FUNCTION test(text) RETURNS bool LANGUAGE plperl as $$
return shift =~ /\xa9/i ? 'true' : 'fal
On Tue, 2007-11-27 at 18:03 +, Simon Riggs wrote:
> 5. DYNAMIC RUN HANDLING (in Final Merge)
>
> Another way of addressing a) is to simply make better use of memory
> itself. Let's look at that in more detail:
>
> Number of runs that can be merged at once is currently fixed, based upon
> avai
[ I'm not very sure of my WITH RECURSIVE syntax, so please excuse any
mistakes ]
On Fri, Nov 30, 2007 at 01:00:27PM +, Gregory Stark wrote:
> Hopefully at the cte call sites we'll be able to gin up enough information to
> fill in the subquery information enough for the planner above to wor
On Nov 30, 2007 1:21 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Just searched my backups and can't seem to find it :( It was on gborg
> > CVS. Where is that now?
>
> Dead.
> But Marc has a tarball of the whole thing somewhere and can find it.
OK, I'll see if I can get a copy of it.
--
Jonah H. Harris wrote:
> On Nov 30, 2007 10:09 AM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
>> Actually, it was PL/Mono. I'll dig through my stuff and post it
>> somewhere for you.
>
> Just searched my backups and can't seem to find it :( It was on gborg
> CVS. Where is that now?
Dead.
But M
On Nov 30, 2007 10:09 AM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
> Actually, it was PL/Mono. I'll dig through my stuff and post it
> somewhere for you.
Just searched my backups and can't seem to find it :( It was on gborg
CVS. Where is that now?
--
Jonah H. Harris, Sr. Software Architect
Josh Berkus <[EMAIL PROTECTED]> writes:
> I disagree. For people who want a quick summary of the major user-facing
> things changed we'll have multiple sources: (a) the announcement, (b) the
> press features list, (c) the Feature-Version matrix. The Release notes
> should have a *complete* li
Heikki,
> This might be worth mentioning, since it can be quite a big difference
> in the right circumstances, and it helps a bit with the scalability
> problem of the recovery. Should mention that it only helps with
> full_pages_writes=on. One more reason to not gamble with data integrity
> ;-).
Greg,
> Frankly I think the release notes are already too long. People who judge a
> release by counting the number of items in the release notes are not worth
> appeasing. Including every individual lock removed or code path optimized
> will only obscure the important points on which people shoul
I wrote:
> One fairly simple answer is to insert a CCI call at the start of
> RevalidateCachedPlan. I dislike that solution, at least by itself,
> on two grounds:
> ...
> I've also thought about rearranging the current conventions for where to
> call CCI. This particular form of the problem would
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I could imagine problems the planner would have to deal with though, such as
>> what type is "bogon" in this query?
>
>> WITH RECURSIVE x(bogon) AS (select bogon from x) select * from x;
>
> Just a note --- that
On Fri, Nov 30, 2007 at 04:43:03PM +0100, Gevik Babakhani wrote:
> > I did look at this at some earlier point as well. One big
> > problem at that time was that once you embedded mono, you had
> > all sorts of threads running in your backend ;-)
>
> yes, threads running around could become a sho
> I did look at this at some earlier point as well. One big
> problem at that time was that once you embedded mono, you had
> all sorts of threads running in your backend ;-)
yes, threads running around could become a show stopper for both Mono and
MS.NET
This is something I want to be sure of b
Gregory Stark <[EMAIL PROTECTED]> writes:
> I could imagine problems the planner would have to deal with though, such as
> what type is "bogon" in this query?
> WITH RECURSIVE x(bogon) AS (select bogon from x) select * from x;
Just a note --- that's not the planner's problem, either. Semantic
in
"Usama Dar" <[EMAIL PROTECTED]> writes:
> i agree that release notes should not be too long, but may be there should
> be (if there isn't one already) something like a "change log" where people
> can find out all the changes done from the previous release, if they are
> intrested ?
The CVS history
On Fri, Nov 30, 2007 at 02:31:44PM +0100, Gevik Babakhani wrote:
>
> I am investigating the possibility of having stored procedures
> and functions written in .NET language flavors. I remember a long time
> ago there was a gborg project wanting to implement it, but that is long
> gone I guess. an
Simon Riggs wrote:
On Fri, 2007-11-30 at 06:31 +, Simon Riggs wrote:
I also notice that two performance features have disappeared from the
release notes. (Presumably they have been removed from source). Both of
them have changes that can be seen by users, so can't see why we would
want them
It would we great. Thank you.
Regards,
Gevik Babakhani
PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
> -Original Message-
> From: [EMAIL PROTEC
On Nov 30, 2007 9:20 AM, Jonah H. Harris <[EMAIL PROTECTED]> wrote:
> Yeah, I have a copy of the old PL/.NET backed up somewhere. IIRC, it
> needs to be rewritten, but it would be possible to make it work for
> both Mono and .NET.
Actually, it was PL/Mono. I'll dig through my stuff and post it
s
On Nov 30, 2007 4:49 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the relea
On Nov 30, 2007 8:31 AM, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
> I am investigating the possibility of having stored procedures
> and functions written in .NET language flavors. I remember a long time
> ago there was a gborg project wanting to implement it, but that is long
> gone I guess. any
Hello
I thought about it. It can be great project. Oracle has similar
project. Performance will be same as PL/Java probably. There is slow
only first call.
Regards
Pavel Stehule
On 30/11/2007, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
>
> I am investigating the possibility of having stored pr
I am investigating the possibility of having stored procedures
and functions written in .NET language flavors. I remember a long time
ago there was a gborg project wanting to implement it, but that is long
gone I guess. anyway
I think there are two possibilities:
a) Use of MS.NET core and i
"Tatsuo Ishii" <[EMAIL PROTECTED]> writes:
> We decided to start working on WITH RECURSIVE too. Currently one of
> our engineers is about to start to look at what has been done and what
> is remaining. We hope to work together with you!
Here's the original message where I posted what I think we
Simon Riggs wrote:
- Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
change to
"Heap-Only Tuples (HOT) improve performance of frequent UPDATEs"
I think we need to qualify this, or it could be quite misleading.
perhaps add "that don't affect indexed columns" or something like
On Thu, Nov 29, 2007 at 05:48:23PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, since EINVAL is the default result from _dosmaperr, and none of
> >> the cases it represents are "expected", why don't we just remove all of
> >> the explicit mappin
On Fri, 2007-11-30 at 09:49 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release no
> "Hubert FONGARNAND" <[EMAIL PROTECTED]> writes:
>
> > Ce message et les éventuels documents joints peuvent contenir des
> > informations confidentielles. Au cas où il ne vous serait pas destiné, nous
> > vous remercions de bien vouloir le supprimer et en aviser immédiatement
> > l'expéditeur. To
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> The patch is very invasive (at least compared to any of my previous
> patches), but so far I haven't managed to find any broken behaviour.
I'm sorry to suggest anything at this point, but... would it be less invasive
if instead of requiring the immedi
On 11/30/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
>
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release not
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> If people understand there aren't 13 performance improvements there are
> at *least* 19+ that is a positive message to help people decide to
> upgrade.
Frankly I think the release notes are already too long. People who judge a
release by counting the
On Fri, 2007-11-30 at 06:31 +, Simon Riggs wrote:
> I also notice that two performance features have disappeared from the
> release notes. (Presumably they have been removed from source). Both of
> them have changes that can be seen by users, so can't see why we would
> want them removed.
Wow
As discussed on -hackers, this patch allows the construction of an
empty array if an explicit cast to an array type is given (as in,
ARRAY[]::int[]).
postgres=# select array[]::int[];
array
---
{}
postgres=# select array[];
ERROR: no target type for empty array
HINT: Empty arrays must be
42 matches
Mail list logo
