Josh Berkus josh@agliodbs.com writes:
I propose a modest experiment: for the 8.3 development cycle, let's try
to agree (in the next month or so) on a roadmap of what major features
should be in 8.3 and who will make each one happen.
Well, I think the what is more important that the who -- we
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 planned straight away, all
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
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 else were you
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 PostgreSQL no longer
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
roll
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 PostgreSQL no longer
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 they
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
first
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.
Yup,
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 worse if
% 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):
% icc
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
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
CALL cmp
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
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)
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
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, we'd make up
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 during
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
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 would
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
Martijn van Oosterhout kleptog@svana.org 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
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
pretty
Martijn van Oosterhout kleptog@svana.org 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
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 mere
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 and I
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
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:
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 is not
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 protocol
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 RETURNING TO myview
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 something more
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 that's
[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
*
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 runs
[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 is
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 good idea?
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, I
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 collected
--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. Does
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
--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
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 are big
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 applied and
* 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
Josh Berkus josh@agliodbs.com 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
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 backend work that
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
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 reload +
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 reviewing
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 number
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 all
Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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
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 Freeze+1
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
do
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. However ---
Josh Berkus josh@agliodbs.com 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
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
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
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.
For what
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 they weren't
Josh Berkus josh@agliodbs.com 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
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 is
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 present
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 the
Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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
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. As I see
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 other people have
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.
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
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 developers
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
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 use, and it does instant
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 the
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
patches. That
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
made
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 the
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 here
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.
Certainly, much
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 it.
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 they never
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 patches they
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
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
1 - 100 of 104 matches
Mail list logo
