Using the same search for 7.4 shows only 48 patch submitters, based on
posts to pgsql-patches ...
Aizaz Ahmed
Alvaro Herrera
Andreas Pflug
Andrew Dunstan
Barry Lind
Bertrand Petit
Bruce Momjian
Bruno Wolff
Christopher Browne
Christopher Kings-Lynne
Dave Cramer
Dennis Björklund
Fernando Nasser
Ga
On Sat, 5 Feb 2005, Marc G. Fournier wrote:
But let me see if I can come up with some *very* rought #s ...
57 ...
Alvaro Herrera
Andreas Pflug
Andrew Dunstan
Andrew Hammond
Bruce Momjian
Christopher Kings-Lynne
Claudio Natoli
Dave Page
David Fetter
Dennis Bjorklund
Ed L.
Fabien COELHO
Gaetano Mendo
On Sat, 5 Feb 2005, Greg Sabino Mullane wrote:
I did it last time. It's been a while now, but I think what I
did was basically look at all the commit messages from the
previous release to the current one, and then used a perl script
to extract everything that looked like a name or an email
address.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> I didn't do it, but it might have been a guess of mine.
>
> Ya, I don't recall doing it either :)
I did it last time. It's been a while now, but I think what I
did was basically look at all the commit messages from the
previous release to the
Josh Berkus writes:
>> How do you get the count? CVS names at the tail of the commit?
> I don't know; Marc and you did it. I'm looking for the number of *people*,
> not the number of patches. So part of it would come from your mailbox.
Trolling through the pgsql-patches archives might work
yOn Fri, 4 Feb 2005, Bruce Momjian wrote:
Josh Berkus wrote:
Marc,
How do you get the count? CVS names at the tail of the commit?
I don't know; Marc and you did it. I'm looking for the number of *people*,
not the number of patches. So part of it would come from your mailbox.
I didn't do it, but
On Fri, Feb 04, 2005 at 05:23:27PM -0500, Stephen Frost wrote:
> As I recall, the default is 100 for statistics, I'd say increase that
> number to like 200 or 300 or more and see if it helps.
No, it's 10.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer som
Josh Berkus wrote:
> Marc,
>
> > How do you get the count? CVS names at the tail of the commit?
>
> I don't know; Marc and you did it. I'm looking for the number of *people*,
> not the number of patches. So part of it would come from your mailbox.
I didn't do it, but it might have been a gu
Sorry, hit the wrong key.
- Forwarded message from Alvaro Herrera <[EMAIL PROTECTED]> -
Date: Fri, 4 Feb 2005 22:39:11 -0300
From: Alvaro Herrera <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] Fixing flat user/group files at database startup
On Fri, Feb 04, 2
Marc,
> How do you get the count? CVS names at the tail of the commit?
I don't know; Marc and you did it. I'm looking for the number of *people*,
not the number of patches. So part of it would come from your mailbox.
--Josh
--
__Aglio Database Solutions___
Josh Berkus
Josh Berkus wrote:
> Marc and/or Bruce:
>
> Hey, for my information (people ask me this a lot) can one of you do a count
> of patch submitters for 8.0? For 7.4, it was around 180.
How do you get the count? CVS names at the tail of the commit?
--
Bruce Momjian| http
Tom Lane wrote:
> Bruce Momjian writes:
> >> In short, fixing this the way Bruce wants to will be a nontrivial amount
> >> of effort.
>
> > psql actually calls get_progname(). Do we know that it will try to link
> > in the other functions from path.c? I am unsure.
>
> I don't know of any commo
[EMAIL PROTECTED] writes:
>-> Index Scan using rt1_zipr, rt1_zipl on rt1 (cost=0.00..121893.93
> rows=30835 width=302)
> Index Cond: ((zipr = 2186) OR (zipl = 2186))
> zipl |925 |
> zipr |899 |
Those n_distinct values for zipl and zipr seem aberrant ---
> [EMAIL PROTECTED] writes:
>> I suspect that analyze only samples a very small amount of the database
>> and gets the wrong idea about it. Is there a way to force analyze to
>> sample more rows?
>
> default_statistics_target. But let's see the pg_stats rows for these
> columns before assuming th
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> I have the USA census TIGER database loaded, the WHOLE THING, the whole
> country. It isn't the biggest database, but it is about 40G before
> indexes. Every table is over a few million rows. I can quite honestly say,
> a sequential scan is almost ne
[EMAIL PROTECTED] writes:
> I suspect that analyze only samples a very small amount of the database
> and gets the wrong idea about it. Is there a way to force analyze to
> sample more rows?
default_statistics_target. But let's see the pg_stats rows for these
columns before assuming that analyze
At 09:02 AM 5/02/2005, Tom Lane wrote:
That strikes me as a bad idea --- what will cause the queue size to
revert to normal, if the batch process fails before resetting it?
Just an idle thought, but each connection to the DB could add a fixed
amount to some queueing parameter. The amount added to
Here's one:
I have the USA census TIGER database loaded, the WHOLE THING, the whole
country. It isn't the biggest database, but it is about 40G before
indexes. Every table is over a few million rows. I can quite honestly say,
a sequential scan is almost never the right thing to do.
Info below.
He
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I think it would be useful to have a means to adjust the queue sizes
> dynamically from a database connection. If the optimum queue sizes
> depend on the workload this would allow things like batch processes to
> tweak the queue sizes for better performa
Bruce Momjian writes:
>> In short, fixing this the way Bruce wants to will be a nontrivial amount
>> of effort.
> psql actually calls get_progname(). Do we know that it will try to link
> in the other functions from path.c? I am unsure.
I don't know of any commonly used linkers that link at gr
On Fri, Feb 04, 2005 at 11:27:40AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > So are you saying you are making T1, T2, B1, and B2 a fixed percentage
> > of the buffer cache rather than making them adjust over time?
>
> B2 goes away entirely (if we keep four lists we violate claim 45) and
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
> >> I suggested to just get_progname() to libpq, not all of path.c. The
> >> odds someone will depend on get_progname() in 8.0 are much less than the
> >> problems we will h
Michael Klatt reported here:
http://archives.postgresql.org/pgsql-admin/2005-02/msg00031.php
that we have problems because the flat files global/pg_pwd
and global/pg_group aren't rebuilt following WAL recovery.
This has in fact been a bug since we created WAL, although it's
certainly far worse in t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
>> I suggested to just get_progname() to libpq, not all of path.c. The
>> odds someone will depend on get_progname() in 8.0 are much less than the
>> problems we will have as listed above.
> Pe
Am Freitag, 4. Februar 2005 17:51 schrieb Bruce Momjian:
> I suggested to just get_progname() to libpq, not all of path.c. The
> odds someone will depend on get_progname() in 8.0 are much less than the
> problems we will have as listed above.
Perhaps a question is in order: Are we sure that get_p
Marc and/or Bruce:
Hey, for my information (people ask me this a lot) can one of you do a count
of patch submitters for 8.0? For 7.4, it was around 180.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 9: the pl
Tom Lane wrote:
> Bruce Momjian writes:
> > So are you saying you are making T1, T2, B1, and B2 a fixed percentage
> > of the buffer cache rather than making them adjust over time?
>
> B2 goes away entirely (if we keep four lists we violate claim 45) and
> the other lists become fixed length, yes
Tom Lane wrote:
> Bruce Momjian writes:
> > I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
> > libpq will still see the 8.0.0 libpq and will still not work.
>
> > That's why the get_progname() addition would be cleaner in some ways.
>
> How you figure that? Your first
Bruce Momjian writes:
> So are you saying you are making T1, T2, B1, and B2 a fixed percentage
> of the buffer cache rather than making them adjust over time?
B2 goes away entirely (if we keep four lists we violate claim 45) and
the other lists become fixed length, yes.
We could also contemplate
Bruce Momjian writes:
> I was asking if the 8.0.0 libpq stays around. If it does then the 7.4.X
> libpq will still see the 8.0.0 libpq and will still not work.
> That's why the get_progname() addition would be cleaner in some ways.
How you figure that? Your first conclusion assumes that someon
Peter Eisentraut wrote:
> Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > Uh, if we bump up the major library version in 8.0.X, will that
> > > > require 8.0.0 user applications to be recompiled?
> > >
> > > No, they just ke
Robert Treat wrote:
Actually i believe people want both syntax's as the former is used by oracle
and the latter by db2 (iirc)
I think the past consensus has been to adopt the SQL standard syntax. Is
there any reason to also support the Oracle syntax other than for
compatibility? (And if that is
Am Donnerstag, 3. Februar 2005 15:42 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > Uh, if we bump up the major library version in 8.0.X, will that
> > > require 8.0.0 user applications to be recompiled?
> >
> > No, they just keep using the old library.
>
> That ass
33 matches
Mail list logo
