Andrew Dunstan wrote:
It would make the process more transparent, which is something several
people have expressed a desire for.
Yes, the processes seems to work by having two of the most important
people waste time on getting information anyone else could collect, or
that the developer hims
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > As an extreme example consider the new Linux release cycle. They have a
> > non-freeze period of a couple weeks, followed by months of frozen time.
> > Users
> > who want to try out new features on different hard
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > Well, no, it's not. We have told people till we're blue in the face
> > "post early, post often". Now I will plead guilty to not always
> > having spent as much time giving feedback on draft patches as I
> > should've, but the p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume this is something we want in /contrib, right?
>
> Peter posted an updated version, I believe.
Ah, it was lower in my mailbox. Thanks.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume this is something we want in /contrib, right?
Peter posted an updated version, I believe.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I was thinking about the business of capturing subtransaction XIDs
during GetSnapshotData so as to reduce the need for visits to
pg_subtrans, as implemented by Takahiro-san here:
http://archives.postgresql.org/pgsql-patches/2006-08/msg00401.php
The principal objection to this, I think, is the longe
Bruce Momjian wrote:
> I see no value in documenting it.
The value in documenting it is that the general awareness about the
progress of development is raised, so more people know where and how to
get involved, as opposed to only three people knowing and the rest
finding out one month after fea
On 9/1/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I pummelled Jonah over the recursive query patch.
He did. Trust me on this... think I still have some bruises too :)
Neither effort was very fruitful, but tracking wasn't what made
them fail. I am not saying tracking is wrong, but rather t
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
> > Another novel idea: have a "bugtracker" of sorts where selected
> > people can add "feature requests" and append patches to them. There,
> > people could add "fake" feature requests describing the stuff they
> > are working on, and publish the pa
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Well, you can grab items from there and apply them. I will remove
> > them from the mailbox when I see the commit. You have another
> > system that will not be significantly more work? Any you can apply
> > them right from the email lists so th
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Uh, Tom has been tracking Gavin on the bitmap patch every week for
> > weeks, and I pummelled EnterpriseDB/Jonah over the recursive query
> > patch.
>
> Great, but where is this documented, so others know about this?
I see no value in documenting
Alvaro Herrera wrote:
> Another novel idea: have a "bugtracker" of sorts where selected
> people can add "feature requests" and append patches to them. There,
> people could add "fake" feature requests describing the stuff they
> are working on, and publish the patches they have for them.
Certain
Alvaro Herrera wrote:
> I've been bitten by having stuff rejected because there was no
> immediate use for them; so I had to maintain them in a private tree,
> where they were subsequently broken by someone else's parallel
> development.
A better version control system would surely seem to help he
Bruce Momjian wrote:
> Well, you can grab items from there and apply them. I will remove
> them from the mailbox when I see the commit. You have another
> system that will not be significantly more work? Any you can apply
> them right from the email lists so they never get to the queue.
What t
Bruce Momjian wrote:
> Uh, Tom has been tracking Gavin on the bitmap patch every week for
> weeks, and I pummelled EnterpriseDB/Jonah over the recursive query
> patch.
Great, but where is this documented, so others know about this?
> Neither effort was very fruitful, but tracking wasn't what
> m
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > It pulls my a mailbox file I use, and it does instant updates as soon
> > > as I change it. It is a URL. Why do people care where it is?
> >
> > The complaint has been that not enough people help with reviewing
> > pa
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > It pulls my a mailbox file I use, and it does instant updates as soon
> > as I change it. It is a URL. Why do people care where it is?
>
> The complaint has been that not enough people help with reviewing
> patches. That would indicate that th
Joshua D. Drake wrote:
>
> >>> They are in the patches queue?
> >>>
> >>> http://momjian.postgresql.org/cgi-bin/pgpatches
> >> Side note::
> >>
> >> Perhaps this would be better served from the main website under the
> >> developer and community sections.
> >
> > It pulls my a mailbox file I u
Bruce Momjian wrote:
> It pulls my a mailbox file I use, and it does instant updates as soon
> as I change it. It is a URL. Why do people care where it is?
The complaint has been that not enough people help with reviewing
patches. That would indicate that the problem is not location but
scala
Gregory Stark <[EMAIL PROTECTED]> writes:
> As an extreme example consider the new Linux release cycle. They have a
> non-freeze period of a couple weeks, followed by months of frozen time. Users
> who want to try out new features on different hardware can do so and often
> turn up problems develop
Bruce Momjian wrote:
Uh, Tom has been tracking Gavin on the bitmap patch every week for
weeks, and I pummelled EnterpriseDB/Jonah over the recursive query
patch. Neither effort was very fruitful, but tracking wasn't what made
them fail. I am not saying tracking is wrong, but rather tracking w
They are in the patches queue?
http://momjian.postgresql.org/cgi-bin/pgpatches
Side note::
Perhaps this would be better served from the main website under the
developer and community sections.
It pulls my a mailbox file I use, and it does instant updates as soon as
I change it. It
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Tom Lane wrote:
> >>> Well, it's taken us the full month to get this far through the queue,
> >>> so I'd sure like to have more people on board reviewing next time.
> >>> Alvaro helped but I miss Neil Conway, and some o
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Well, no, it's not. We have told people till we're blue in the face
> > "post early, post often". Now I will plead guilty to not always
> > having spent as much time giving feedback on draft patches as I
> > should've, but the process is pretty clear.
Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
Well, it's taken us the full month to get this far through the queue,
so I'd sure like to have more people on board reviewing next time.
Alvaro helped but I miss Neil Conway, and some other people have
helped in the past. However -
Tom Lane wrote:
> Josh Berkus writes:
> > No, it's not. There's a bunch of patches which we had nothing on -- not
> > spec, not design draft, not anything -- until we got them on July 20th.
> > Our current system is to have only one deadline,
>
> Well, no, it's not. We have told people till
Josh Berkus wrote:
> Bruce, Tom, all:
>
> > No rejiggering is going to get people to complete things they didn't
> > complete under the old system.
>
> It'll help the new people. A lot of people -- if not most -- submitting
> their first major patch to PostgreSQL dramatically underestimate th
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Well, it's taken us the full month to get this far through the queue,
> > so I'd sure like to have more people on board reviewing next time.
> > Alvaro helped but I miss Neil Conway, and some other people have
> > helped in the past. However --- the p
Tom Lane wrote:
> Well, no, it's not. We have told people till we're blue in the face
> "post early, post often". Now I will plead guilty to not always
> having spent as much time giving feedback on draft patches as I
> should've, but the process is pretty clear. As I see it the main
> problem i
Josh Berkus writes:
> No, it's not. There's a bunch of patches which we had nothing on -- not
> spec, not design draft, not anything -- until we got them on July 20th.
> Our current system is to have only one deadline,
Well, no, it's not. We have told people till we're blue in the face
"pos
Tom Lane <[EMAIL PROTECTED]> writes:
>> If you look at the two "incomplete" patches, and the "misfired" one
>> (Bitmaps, Updatable Views, and WITH RECURSIVE) all of them are patches
>> where the submitter had been working on them months ago, and might have
>> made the release (or let us know t
Gavin Sherry <[EMAIL PROTECTED]> writes:
> On Fri, 1 Sep 2006, Tom Lane wrote:
>> My feeling is that we ought to bounce bitmap indexes and updatable views
>> as not being ready, accept all the contrib stuff, and try to get the
>> other items done in time for a beta at, say, the end of next week.
>
Bruce, Tom, all:
> No rejiggering is going to get people to complete things they didn't
> complete under the old system.
It'll help the new people. A lot of people -- if not most -- submitting
their first major patch to PostgreSQL dramatically underestimate the
amount of fix-up that's going
On Fri, 1 Sep 2006, Tom Lane wrote:
> My feeling is that we ought to bounce bitmap indexes and updatable views
> as not being ready, accept all the contrib stuff, and try to get the
> other items done in time for a beta at, say, the end of next week.
For what it's worth, Jie and I hope to have fi
Alvaro Herrera wrote:
Joshua D. Drake wrote:
It does not mean all those features are useful, they definitely are. I
am just trying to look at it from at:
WHIZ* BANG* POW* perspective.
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and thanks'),
(
Therefore I propose that we adopt the following schedule for 8.3, assuming
an September 1 Beta date:
June 1: Specification Freeze: specifications for all new features due
I would suggest the above be:
June 1: Specification Freeze: specifications for all new features due &
approved.
The l
Josh Berkus writes:
> Bruce,
>>> What's VC?
>>
>> MS Visual C++
> Given that this could lead to us recruiting more developers out of our
> Windows user base, I'd prioritize it.
Yeah, that's why I listed it as a major item. I haven't had a chance to
look at the patch, but if it's not too ugly
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, it's taken us the full month to get this far through the queue, so
>> I'd sure like to have more people on board reviewing next time. Alvaro
>> helped but I miss Neil Conway, and some other people have helped in the
>> past. How
Joshua D. Drake wrote:
> Let's take multiple-argument aggregate functions for example... The
> marketable portion of that is limited. 85% of the people we are
> marketing too don't even know what that means. Heck, I haven't even
> run into the pervious limitation :)
As far as market analysis goes,
Tom Lane wrote:
> Well, it's taken us the full month to get this far through the queue,
> so I'd sure like to have more people on board reviewing next time.
> Alvaro helped but I miss Neil Conway, and some other people have
> helped in the past. However --- the present situation has nothing to
>
Josh Berkus wrote:
> Bruce,
>
> > > What's VC?
> >
> > MS Visual C++
>
> Given that this could lead to us recruiting more developers out of our
> Windows user base, I'd prioritize it.
>
> Overall, I think this whole process is pointing up that there's a problem
> with our historic Feature Free
Tom Lane wrote:
> Josh Berkus writes:
> > Can you be a little clearer on which things are non-working patches, and
> > which things are pending due to lack of review?
>
> The only things I currently want to reject as not having provided a
> timely patch are bitmap indexes and updatable views. T
Joshua D. Drake wrote:
> It does not mean all those features are useful, they definitely are. I
> am just trying to look at it from at:
>
> WHIZ* BANG* POW* perspective.
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and thanks'),
(142857, 3, 'for al
Bruce,
> > What's VC?
>
> MS Visual C++
Given that this could lead to us recruiting more developers out of our
Windows user base, I'd prioritize it.
Overall, I think this whole process is pointing up that there's a problem
with our historic Feature Freeze+1 month|beta|RCs cycle. Given the num
Tom Lane wrote:
> > I'm all for bouncing
> > stuff that's not ready to go, but bouncing stuff because we haven't
> > recruited enough code reviewers is just bad practice.
>
> Well, it's taken us the full month to get this far through the queue, so
> I'd sure like to have more people on board re
Josh Berkus wrote:
> Tom,
>
> > September is upon us and it doesn't seem like we are ready to ship
> > a beta. I think it's time to start making some hard choices.
> >
> > In the main code I see these outstanding features/patches:
> >
> > * bitmap indexes
> > * updatable views
> > * GUC variable
Josh said nearly the same in core's discussion, but come now. The
updateable-view patch (in its current form) does not offer *one single
thing* you can't do today, indeed for many PG releases past; it just
saves writing out some tedious rules.
Sure, I can write the rules, you can write the rul
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> My feeling is that we ought to bounce bitmap indexes and updatable views
>> as not being ready, accept all the contrib stuff, and try to get the
>> other items done in time for a beta at, say, the end of next week.
> I know there is a lot of "backen
Josh Berkus writes:
> Can you be a little clearer on which things are non-working patches, and
> which things are pending due to lack of review?
The only things I currently want to reject as not having provided a
timely patch are bitmap indexes and updatable views. The other stuff
I mentioned i
* Tom Lane ([EMAIL PROTECTED]) wrote:
> My feeling is that we ought to bounce bitmap indexes and updatable views
> as not being ready, accept all the contrib stuff, and try to get the
> other items done in time for a beta at, say, the end of next week.
I agree with bouncing these to get the beta o
Tom,
> September is upon us and it doesn't seem like we are ready to ship
> a beta. I think it's time to start making some hard choices.
>
> In the main code I see these outstanding features/patches:
>
> * bitmap indexes
> * updatable views
> * GUC variable reload + refactoring (previously applie
Tom Lane wrote:
> September is upon us and it doesn't seem like we are ready to ship
> a beta. I think it's time to start making some hard choices.
>
> In the main code I see these outstanding features/patches:
>
> * bitmap indexes
> * updatable views
IMHO these two should be bounced. They ar
--On Freitag, September 01, 2006 11:41:16 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
So in other words, views on serial columns don't work? I don't think
that's going to be acceptable.
They work in such a case that someone isn't allowed to put a volatile
function in an update query
N
My feeling is that we ought to bounce bitmap indexes and updatable views
as not being ready, accept all the contrib stuff, and try to get the
other items done in time for a beta at, say, the end of next week.
I'm not thrilled about postponing those two large items till 8.3, but
we are a month p
--On Freitag, September 01, 2006 11:34:49 -0400 Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
I don't understand this part very well. Say if you have a view WITH
CHECK OPTION whose condition is "foo > 5", and then define a view WITH
LOCAL CHECK OPTION on top of that, whose condition is "bar > 5".
On 9/1/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Bernd Helmle wrote:
> <[EMAIL PROTECTED]> wrote:
> >* It's too early in the morning for me to be clear about the difference
> >between CASCADED and LOCAL CHECK OPTION --- I think that this would
> >merely alter the set of check constraints co
I wrote:
> After some further thought, I think we could make it work if we treat
> XXX RETURNING as a distinct rule event type and make the following
> restrictions (which are exactly analogous to the restrictions for ON
> SELECT rules) for ON XXX RETURNING rules:
After working on this for a bit,
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > I little bit enhanced overview catalog tables. I added two new columns.
> > First one is OID of catalog table and second one contains attributes
> > which determine if the table is bootstrap, with oid and global.
>
> Why is this a g
On Fri, September 1, 2006 22:14, Gregory Stark wrote:
> I think the slow part is trying to figure out whether to count the current
> call as a hit or a miss. How do you determine whether the plan you're
> running
> is the best plan without replanning the query?
The question of knowing which plan
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Revert change to turn autovacuum on by default.
It looks like you reverted that whole patch including the changes to the
default autovacuum threshold/scale parameters. I'd be inclined to keep those.
regards, tom lane
---
Gregory Stark <[EMAIL PROTECTED]> writes:
> Mem RunsTime
>
> 1MB 18 8.25s
> 10MB 3 5.6s
> 100MB qsort 6.1s
I'm confused what this means exactly? Are you saying that in the first
two cases, there were 18 and 3 sorted
(I've already bounced this off the core committee, but it's time for
wider discussion.)
September is upon us and it doesn't seem like we are ready to ship
a beta. I think it's time to start making some hard choices.
In the main code I see these outstanding features/patches:
* bitmap indexes
* u
[Quick note: sorry if you received this mail multiple times,
i've moved to a new workstation and my MUA gots hosed up
with its identities (all of them has the same adress, suddenly)
and I recognized that too late.i'm sorry]
--On Freitag, September 01, 2006 10:03:42 -0400 Tom Lane
<[EMAIL
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> What version of pgsql?
>
> Recent changes stripped the sort set down considerably in size in external
> sort, I'm not sure the same is done if the data doesn't spill to disk.
This is a recent CVS checkout.
If you're referring to MinimalTuples I think
Bernd Helmle <[EMAIL PROTECTED]> writes:
> What we can do is to restrict view updates that involves a volatile function
> completely. As soon as the rewriter wants to apply an implicit system rule
> to a current query which holds volatile functions, we could treat this as
> an error.
So in other
Bernd Helmle wrote:
> <[EMAIL PROTECTED]> wrote:
> >* It's too early in the morning for me to be clear about the difference
> >between CASCADED and LOCAL CHECK OPTION --- I think that this would
> >merely alter the set of check constraints collected for a particular
> >query, but if there's somet
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 8/15/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I'm tempted to suggest that the RETURNING commands might need to be
>> separate rule events, and that to support this you'd need to write
>> an additional rule:
>>
>> CREATE RULE r1 AS ON INSERT RETUR
On Fri, Sep 01, 2006 at 10:18:37AM -0400, Tom Lane wrote:
> Sure, but how much does it really matter? If you don't want the plan
> saved for reuse, merely avoiding retransmission of the query text does
> not seem like a major win. Having had time to think about it, I no
> longer think the protoco
On Fri, September 1, 2006 21:30, Tom Lane wrote:
> Yeah. One of the reasons the planner is acceptably fast is that it is
> aggressive about discarding candidate plans as soon as they are clearly
> inferior to other plans. Tracking multiple plans that might be optimal
> under varying assumptions
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Fri, September 1, 2006 16:53, Martijn van Oosterhout wrote:
>
>> Interesting thought. It might be worth trying. But my big question: is
>> all this testing and counting actually going to be faster than just
>> replanning? Postgresql's planner
What version of pgsql?
Recent changes stripped the sort set down considerably in size in external
sort, I'm not sure the same is done if the data doesn't spill to disk.
- Luke
Sent by GoodLink (www.good.com)
-Original Message-
From: Gregory Stark [mailto:[EMAIL PROTECTED]
Sent: F
> I'm not sure if this is good news or bad news. Either some kudos are due to
> the gang that worked on the external sort performance or something's very
> wrong with the qsort implementation in glibc because I'm seeing Postgres's
> external sort perform better than qsort.
And here's a really pe
On Thu, Aug 31, 2006 at 12:11:46 +0400,
"Victor B. Wagner" <[EMAIL PROTECTED]> wrote:
>
> It contains !MD5 element, because MD5 digest algorithm was broken about
> year ago, and PostgreSQL expected to work with versions of OpenSSL which
> still consider it strong.
MD5 wasn't completely broken a
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I little bit enhanced overview catalog tables. I added two new columns.
> First one is OID of catalog table and second one contains attributes
> which determine if the table is bootstrap, with oid and global.
Why is this a good idea? It seems like mer
Martijn van Oosterhout writes:
> Interesting thought. It might be worth trying. But my big question: is
> all this testing and counting actually going to be faster than just
> replanning? Postgresql's planner is not that slow.
> ...
> The thing is that number of possible plans is going to be propo
On Fri, Sep 01, 2006 at 11:53:11AM +0200, Martijn van Oosterhout wrote:
> On Fri, Sep 01, 2006 at 03:56:19PM +0700, Jeroen T. Vermeulen wrote:
> > That's a very common thing in processor design as well, and there's a
> > standard trick for it: the saturating two-bit counter. It tends to work
> > p
Martijn van Oosterhout writes:
>> The server has to prepare the query sometime. The v3 protocol just gives you
>> control over when that happens, but it doesn't force you to do it at any
>> particular time.
> Not really. All named prepares are planned straight away, all unnamed
> ones are planned
I'm not sure if this is good news or bad news. Either some kudos are due to
the gang that worked on the external sort performance or something's very
wrong with the qsort implementation in glibc because I'm seeing Postgres's
external sort perform better than qsort.
This is despite Postgres extern
On Fri, September 1, 2006 16:53, Martijn van Oosterhout wrote:
> Interesting thought. It might be worth trying. But my big question: is
> all this testing and counting actually going to be faster than just
> replanning? Postgresql's planner is not that slow.
In the best case (which of course woul
--On Donnerstag, August 31, 2006 11:10:47 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
The problem is not with the view condition. Consider
CREATE TABLE data (id serial primary key, ...);
CREATE VIEW only_new_data AS SELECT * FROM data WHERE id > 12345
WITH CHECK
On Sep 1, 2006, at 20:39 , Michael Glaesemann wrote:
Here's a patch that appears to work. Gives the same output with and
without --enable-integer-datetimes. Answers look like they're correct.
I'm basically treating the components as three different intervals
(with the other two components
Bernd Helmle <[EMAIL PROTECTED]> writes:
> I would like to try to grab your idea to push down the CHECK OPTION logic
> down to the executor as a (table/view?) constraint. Would that be an idea
> worth to consider and,
> most important, is this doable? I don't have that much experience in the
> e
Joshua D. Drake wrote:
>>> we will know whether this is a great thing we should continue, or we
>>> should stick to our traditional laissez-faire style of project
>>> management. I figure that even if it really sucks, it wouldn't kill us
>>> to try it for one release cycle --- at the very worst, w
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> Is it worth looking into the overflow and subtraction issues for 8.2?
> It seems to me they're bugs rather than features. Or are these 8.3
> since it's so late?
IMHO they're bugs not new features, and therefore perfectly fair game
to work on dur
Please ignore the patch I just sent. Much too quick with the send
button.
Michael Glaesemann
grzm seespotcode net
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your
Here's a patch that appears to work. Gives the same output with and
without --enable-integer-datetimes. Answers look like they're correct.
I'm basically treating the components as three different intervals
(with the other two components zero), rounding them each to usecs,
and adding them to
What does that option do? Is it practical to enable it for the entire
backend?
From docs:
Disables inline expansion of standard library or intrinsic functions.
And isn't this a straightforward compiler bug they should be notified
about?
What's a choice? Now I see 3:
1) -O1
2) "volatile"
3) -no
Hi, guys
i have already send a undescribe request to [EMAIL PROTECTED],
but i receive a reject reply.
who can tell me how to undescribe it ?
thanks.
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: "zhou bo" <[EMAIL PROTECTED]>
Subject: Majordomo results: unsubscribe pgsql-h
On Wednesday 30 August 2006 05:12, Devrim GUNDUZ wrote:
> Hello,
>
> Yesterday night, I was approved (sponsored) for Fedora Core packaging
> (please note that this is not something financial).
>
> For the beginning, I officially submitted python-psycopg2 to FC6. More
> are on the way; like pgpool,
On Fri, Sep 01, 2006 at 03:10:44PM +0400, Teodor Sigaev wrote:
> BTW, this example works correct with -nolib-inline
> (http://www.intel.com/software/products/compilers/clin/docs/main_cls/mergedprojects/copts_cls/ccpp_options/option_nolib_inline.htm):
> % icc -O2 -nolib_inline -o 1 1.c&& ./1
> CAL
% icc -O2 -o 1 1.c && ./1
CALL cmp
SET SI = 1
BUG: SI==0
% icc -O1 -o 1 1.c && ./1
CALL cmp
SET SI = 1
OK
BTW, this example works correct with -nolib-inline
(http://www.intel.com/software/products/compilers/clin/docs/main_cls/mergedprojects/copts_cls/ccpp_options/option_nolib_inline.htm):
% ic
On Sep 1, 2006, at 11:03 , Bruce Momjian wrote:
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that? I think the 23:60 is a time rounding
issue that isn't covered in this patch.
> > I don't chime in very often, but I do think the refusal to
incorporate
> > hints into the planner system is fantastically stubborn and
> > nonsensical.
>
> What is actually fantastically nonsensical about this is that
> the issues I outlined about prepared statements would merely
> become
On Sep 1, 2006, at 11:31 , Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I am unclear about this report. The patch was not meant to fix
every
interval issue, but merely to improve multiplication and division
computations. Does it do that?
According to Mi
> Anyway, your plan assumes that you have information to work
> with. The current system plans prepared queries with no
> information at all about parameters and people are advocating
> to keep it that way. I think a good first step would be the
> plan on first execution, like Oracle does.
Yu
On Fri, Sep 01, 2006 at 03:56:19PM +0700, Jeroen T. Vermeulen wrote:
> That's a very common thing in processor design as well, and there's a
> standard trick for it: the saturating two-bit counter. It tends to work
> pretty well for branch prediction, value prediction etc. Usually it's the
> firs
Huh, it's a over-optimization by icc on Itanium. With -00 or -02 there
is no any problem, only -O2 produces such effect. The problem is in code
Sorry, right "With -00 or -01 there is no any problem"
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Thu, August 31, 2006 21:41, Phil Frost wrote:
>> Is there any kind of pattern at all to this problem? Anything
>> recognizable? A few typical pitfalls?
>
> Frequently I have found preplanning will result in a horrible plan
> because it is assumed parameters may be volatile while in practice t
> >> My bet is something depending on GetTickCount to measure elapsed
time
> >> (and no, it's not used in the core Postgres code, but you've got
> >> plenty of other possible culprits in that stack).
>
> > This doesn't quite make sense. The only reason we have to reboot is
> > because PostgreS
Oops, going backwards through the mails it seems :)
> Subsequent connections to the database will fail (such as pgAdmin)
> and Windows must be completely rebooted.
Fail in what way. Hang, not connect, or get an error msg?
> PostgreSQL will also not recover on its own (e.g; auto restart and
> rol
1 - 100 of 104 matches
Mail list logo
