Any ETA? I don't mean to harp, but it looks really bad when someone new
to postgresql comes to investigate something and the site is just
crawling.
Well the backup should come up in a couple of weeks. I know that the new
pgFoundry is being worked on right now. Josh would have a better idea.
Sincere
On Fri, Apr 29, 2005 at 11:21:35PM -0700, Joshua D. Drake wrote:
> >
> >
> >If money's not an issue anymore, can we get a bigger box to host
> >pgfoundry on then? :)
>
> It's been done and is in the process of being brought up at a new colo
> facility. There is also a backup box being built for f
Anyone interested in pooling funds for features should take a look at
http://people.freebsd.org/~phk/funding.html, which is about a FreeBSD
developer who offered to work full-time on developing some specific
features should enough people donate. Also worthy of mention is
http://www.freebsdfoundatio
If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
It's been done and is in the process of being brought up at a new colo
facility. There is also a backup box being built for failover purposes ;)
Sincerely,
Joshua D. Drake
Command Prompt, Inc.
--
On Fri, Apr 29, 2005 at 11:02:51PM -0700, Joshua D. Drake wrote:
> Right now on the front page when we ask for support we are asking for
> people to donate money. We don't need money. We need people. The support
> link goes to bandwidth but a great deal of the project is hosted over
> many, many s
We'd like to avoid such unpleasant surprises, but how to get the word
out?
More prominent placement of how to contribute would probably help. The
PGF could help with this as well once it is done. Right now it is ether
on how to contribute unless you know where to look.
Right now on the front pa
On Fri, 29 Apr 2005, Andrew Dunstan wrote:
> One thing that might help is a more open sponsorship "clearing house".
> Example (not meant as a bid, but just to illustrate): the JDBC driver
> needs a scanner overhaul - it breaks on dollar quoting and a bunch of
> other stuff. I could do that wo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Regarding the secret code stuff - I predict that it will quickly bite
> whoever does it, unless they are extremely lucky.
Yeah. Bruce and I were worrying about this on the phone today.
If a company is doing some work with the intent that it's a propri
Marc G. Fournier wrote:
On Fri, 29 Apr 2005, Christopher Browne wrote:
Some reasonable approximations might include:
- How much disk I/O was recorded in the last 60 seconds?
- How many application transactions (e.g. - invoices or such) were
issued in the last 60 seconds (monitoring a sequence cou
Andrew Dunstan wrote:
>
> I've deliberately let the dust settle slightly on this.
>
> One thing that might help is a more open sponsorship "clearing house".
> Example (not meant as a bid, but just to illustrate): the JDBC driver
> needs a scanner overhaul - it breaks on dollar quoting and a bun
On Fri, 29 Apr 2005, Christopher Browne wrote:
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Marc G. Fournier") wrote:
I know one person was talking about being able to target only those
that pages that have changes, instead of the whole table ... but some
sort of "load monitoring"
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Marc G.
Fournier") wrote:
> I know one person was talking about being able to target only those
> that pages that have changes, instead of the whole table ... but some
> sort of "load monitoring" that checks # of active connections and
Hi,
While trying to determine if SPI_cursor_move can rewind
(and receiving a great help from the guys at the irc), we
found out that since the count parameter is int
and FETCH_ALL is LONG_MAX then setting
the count parameter to FETCH_ALL to rewind
will not work on 64bit systems.
On my pIII 32 bit
On Fri, 29 Apr 2005, Tom Lane wrote:
> >-> Index Scan using ipix_idx on q3c (cost=0.01..9686.37 rows=35
> > width=48) (actual time=0.006..0.006 rows=0 loops=300)
> > Index Cond: ((q3c.ipix >= ("outer".ipix - 1000)) AND (q3c.ipix <=
> > ("outer".ipix - 993)))
>
> >
I think what you're suggesting is that vacuum settings (most likely
delay) take into consideration the load on the database, which I think
is a great idea. One possibility is if vacuum tracks how many blocks
it's read/written, it can see how many blocks the database has done
overall; subtract the t
I've deliberately let the dust settle slightly on this.
One thing that might help is a more open sponsorship "clearing house".
Example (not meant as a bid, but just to illustrate): the JDBC driver
needs a scanner overhaul - it breaks on dollar quoting and a bunch of
other stuff. I could do that
On Fri, Apr 29, 2005 at 10:17:44AM -0400, Tom Lane wrote:
> Our experience with trying to write single files to serve both server
> and client sides has been, um, painful. I recommend you not try this.
BTW, why not get rid of src/corba?
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"XML!" Exclaimed
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I'd like to report about suprising (for me) results of performance testing of
> bitmap indexes in nested loop join plans.
I'm surprised too. There's something weird in the indexscans
themselves:
>-> Index Scan using ipix_idx on q3c (cost=
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Fri, Apr 29, 2005 at 10:36:05AM -0400, Tom Lane wrote:
>> regression=# select (xyz(unique1,unique2)).* from tenk1 limit 5;
> This is a little off topic, but I've noticed that the above invokes
> the function once per output column:
Yeah, that is unfor
On Fri, Apr 29, 2005 at 10:36:05AM -0400, Tom Lane wrote:
>
> regression=# select (xyz(unique1,unique2)).* from tenk1 limit 5;
This is a little off topic, but I've noticed that the above invokes
the function once per output column:
CREATE FUNCTION xyz(INOUT x integer, INOUT y integer, OUT z integ
On Fri, 29 Apr 2005, Tom Lane wrote:
"Matthew T. O'Connor" writes:
What to people think about having an optional "maintenance window" so
that autovac only takes action during an approved time. But perhaps
just using the vacuum delay settings will be enough.
I'm not sure autovac should go complete
"Matthew T. O'Connor" writes:
> What to people think about having an optional "maintenance window" so
> that autovac only takes action during an approved time. But perhaps
> just using the vacuum delay settings will be enough.
I'm not sure autovac should go completely catatonic during the day;
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2005-04-28 at 02:11 -0400, Tom Lane wrote:
>> Hm, I wonder if there is something broken about the "SQL parsing" logic
>> in _sendSQLLine, such that it could go into an infinite loop given the
>> right input?
> Let me see if I can put together a test
On Fri, Apr 29, 2005 at 12:43:37 -0300,
"Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Apr 2005, Bruno Wolff III wrote:
>
> Except for the surprise of peridically having the system go unresponsive
> because it hit a large table, and that new user wondering what is wrong
> with post
On Fri, 29 Apr 2005, Bruno Wolff III wrote:
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian wrote:
Tom Lane wrote:
Christopher Browne <[EMAIL PROTECTED]> writes:
In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
o integrated auto-vacuum (Bruce)
If this can kick of
Tom Lane wrote:
Christopher Browne <[EMAIL PROTECTED]> writes:
If this can kick off a vacuum of a Very Large Table at an unfortunate
time, this can turn out to be a prety painful misfeature.
[ shrug... ] You'll always be able to turn it off if you don't want it.
I'm not sure that we'll be
On Fri, Apr 29, 2005 at 10:09:43 -0400,
Bruce Momjian wrote:
> Tom Lane wrote:
> > Christopher Browne <[EMAIL PROTECTED]> writes:
> > > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian)
> > > wrote:
> > >> o integrated auto-vacuum (Bruce)
> >
> > > If this can kick off a vac
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Ideally I'd like to write something like this:
> SELECT xyz(a, b) AS (x int, y int, z timestamptz) FROM abc;
> but that yields a syntax error.
While that's probably doable if anyone were really motivated,
I'm not sure it's worth the trouble in view o
Brent Verner <[EMAIL PROTECTED]> writes:
> Now, the hard part...where should this code live? I'm thinking a
> src/transport directory seems sensible.
Our experience with trying to write single files to serve both server
and client sides has been, um, painful. I recommend you not try this.
My
Hello All,
I'd like to report about suprising (for me) results of performance testing of
bitmap indexes in nested loop join plans.
I have the table q3c
test=# \d q3c
Table "public.q3c"
Column | Type | Modifiers
++---
ipix | bigint |
errbox | box|
ra
Tom Lane wrote:
> Christopher Browne <[EMAIL PROTECTED]> writes:
> > In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> >> o integrated auto-vacuum (Bruce)
>
> > If this can kick off a vacuum of a Very Large Table at an unfortunate
> > time, this can turn out to be a pre
Christopher Browne <[EMAIL PROTECTED]> writes:
> In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
>> o integrated auto-vacuum (Bruce)
> If this can kick off a vacuum of a Very Large Table at an unfortunate
> time, this can turn out to be a prety painful misfeature.
[ sh
Hello, pgsql-hackers.
I have an idea ( :-) ) about
SELECT field1,agregate(field2) FROM view GROUP BY field1;
(and its variant SELECT agragate(field2) FROM view)
where view is SELECT ... UNION ALL ... :
As i understood from thread
http://archives.postgresql.org/pgsql-performance/2004-1
In the last exciting episode, pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> o integrated auto-vacuum (Bruce)
If this can kick off a vacuum of a Very Large Table at an unfortunate
time, this can turn out to be a prety painful misfeature.
What I'd _really_ love to see (and alas, it's beyond
Well, this guy has it nailed. He cites Flajolet and Martin, which was (I
thought) as good as you could get with only a reasonable amount of memory per
statistic. Unfortunately, their hash table is a one-shot deal; there's no way
to maintain it once the table changes. His incremental update doesn
On Thu, 2005-04-28 at 02:11 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Tue, 2005-04-26 at 23:22 -0400, Tom Lane wrote:
> >> You tell us ;-). You've got the test case, attach to it with a debugger
> >> and find out what it's doing.
>
> > I wasn't entirely sure how to "c
36 matches
Mail list logo
