Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 07:04:07PM -0400, Gregory Stark wrote:
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
> >>> I'd wish that we reconsider when and how prepared statements are
> >>> used. The JDBC interface and PL/pgSQL are frequently noticed
> >>> perpetrators, but the problem is really all over the place.
> >> AFAIK those are the only two places where preparation is
> the default
> >> ... what
On Fri, Sep 01, 2006 at 09:26:24AM +0200, Lukas Kahwe Smith wrote:
> AFAIK since Oracle 9i planning is always deferred until the first
> execution. This way they hope to get a better plan, which would
> obviously not be possible if the selectivity varies greatly.
Interesting.
> So are the plans
> >> 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
> >> 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
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
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 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
> 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
> > 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
% 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: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
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.
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
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,
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
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
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
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
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
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
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
--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 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
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
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
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:
> 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
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
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
> 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
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
"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
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
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
"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
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
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
"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
[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
(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
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
[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
---
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
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
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,
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
--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".
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: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
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
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 ([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
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
"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 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
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
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
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
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
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
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:
> 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
>
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,
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
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
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
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'),
(
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
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
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.
>
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
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 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
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
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
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
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 -
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.
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
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
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
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:
> 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
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
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
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
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:
> 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
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
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
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
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:
> 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
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
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
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 <[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
1 - 100 of 104 matches
Mail list logo
