On Sat, 2007-11-24 at 00:04 -0500, Tom Lane wrote:
> I didn't intend to say that select-only transactions aren't interesting;
> rather that there should be some minimal effort on the application side.
> The cases we are testing here involve:
>
> 1. One query per transaction. Even with the 8.3 im
On Nov 24, 2007 11:35 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On the plus side, there are many very savvy people out there too and all
> the performance features we put in are being used in serious ways. But
> we must cater for both the top end and bottom end of the application
> spectrum.
To
On Nov 22, 2007 7:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
> > I thought I could also perform a test on CVS head every month from
> > December 2006 to now to see if it can give us a better idea of when
> > the overhead first appeared. Ping me if you'
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Tom, from my tests, the slow down goes down from 8% to 4% but it's
> still there and measurable. It's pretty consistent with the fact that
> you only saw a 3% slow down in your tests.
> The fact that you had only 3% overhead is still bugging me thoug
On Nov 24, 2007 5:16 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> This is a conflict which will affect Postgres in the future as well. Generally
> I/O costs win over cpu costs in databases since only relatively small systems
> are cpu-bound. Large systems are typically I/O-bound.
It really depen
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> And the most important point IMHO is that we must be aware of the
> trade-offs we make. We might have some cases where the CPU trade-off
> is not worth the I/O improvement (and probably the other case too).
> We really need a test framework to be abl
D'Arcy J.M. Cain wrote:
> On Sat, 24 Nov 2007 11:27:38 -0500 (EST)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I am confused about two other items with MONEY. First, why can't
> > anything but a string be cast to this type?
> >
> > test=> select 871234872319489323::money;
> > ERROR: c
Peter, were you going to address this?
---
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Bruce's suggestion of somehow checking this in the top Makefile is
> > a possibility, but even better would be if creating configure fr
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Albe Laurenz wrote:
> >> If the postmaster is stopped with 'pg_ctl stop' while an
> >> online backup is in progress,
I have updated the patches queue with open 8.3 items:
http://momjian.postgresql.org/cgi-bin/pgpatches
FYI, I worked with a Borland CC user offlist and 8.3 CVS now compiles
cleanly for him.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB
On 11/24/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I have updated the patches queue with open 8.3 items:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
The "Cleaner API for appendStringInfoVA" belongs to 8.4, if accepted.
It is not serious enough for 8.3.
--
marko
---
Marko Kreen wrote:
> On 11/24/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I have updated the patches queue with open 8.3 items:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
>
> The "Cleaner API for appendStringInfoVA" belongs to 8.4, if accepted.
>
> It is not serious enou
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have updated the patches queue with open 8.3 items:
> http://momjian.postgresql.org/cgi-bin/pgpatches
Re: [DOCS] Normalized Ranking example incorrect in text search, Tom Lane
This is done already.
Re: [HACKERS] Heads up: 8.3beta3 to be wrapped
On Sat, 24 Nov 2007, Tom Lane wrote:
[PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs
Applied.
Getting positive feedback that your archive command has triggered is
helpful for new users of this feature, and making it so that doesn't
happen anymore is a step backwards
On Nov 24, 2007 5:16 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Several of the major changes in 8.3 are I/O vs CPU tradeoffs which could be
> causing a slowdown if you're measuring primarily CPU resources. I'm thinking
> of both HOT and packed varlenas. I don't know if either of these are causi
I wrote:
> Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew
> This too.
Uh, no, actually it isn't. I thought we were going to make cases
like "" be treated as XML tags, but CVS HEAD fails to do that:
regression=# select * from ts_debug('foo');
alias | description
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have updated the patches queue with open 8.3 items:
> > http://momjian.postgresql.org/cgi-bin/pgpatches
>
> Re: [DOCS] Normalized Ranking example incorrect in text search, Tom Lane
>
> This is done already.
>
> Re: [HACKERS] H
Greg Smith <[EMAIL PROTECTED]> writes:
> Sorry I didn't speak up before, I didn't think this was even a serious
> candidate for applying to 8.3. Seemed like too much of a functional
> change for slipping in this late and I presumed it was just going into the
> 8.4 queue.
Changing the log level
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have updated the patches queue with open 8.3 items:
> http://momjian.postgresql.org/cgi-bin/pgpatches
Some other things that I think are open issues for 8.3:
Poorly designed tsearch NOTICEs
http://archives.postgresql.org/pgsql-hackers/2007-10/ms
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Any feature additions to MONEY will be for 8.4. What is this doing
>> in the 8.3 list?
> The point is if we are un-depricating the data type, do we want to do it
> with such limited usefulness? I am concerned it will get wider usage
D'Arcy J.M. Cain wrote:
> Log Message:
> ---
> Add regression tests for MONEY type.
This has broken the buildfarm ...
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"You knock on that door or the sun will be shining on places inside you
that the sun does
On 11/24/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> This is a conflict which will affect Postgres in the future as well.
> Generally
> I/O costs win over cpu costs in databases since only relatively small
> systems
> are cpu-bound. Large systems are typically I/O-bound.
>
That really depends
Hello all,
testing 8.3b3, i found out an interesting thing:
we have some plpgsql functions which use quote_literal() regardless of
the data type. With Beta 3 this does not work anymore[1].
Given the fact, that some functions do a lot of work, you (or at least
we) don't want to look, if the data
"Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> writes:
> we have some plpgsql functions which use quote_literal() regardless of
> the data type. With Beta 3 this does not work anymore[1].
If you're unwilling to fix your application, you can hack around that
for yourself.
regression=# select quote_
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On Nov 24, 2007 5:16 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> Several of the major changes in 8.3 are I/O vs CPU tradeoffs which could be
>> causing a slowdown if you're measuring primarily CPU resources. I'm thinking
>> of both HOT and packed
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Any feature additions to MONEY will be for 8.4. What is this doing
> >> in the 8.3 list?
>
> > The point is if we are un-depricating the data type, do we want to do it
> > with such limited usefulness? I am conc
Tom Lane wrote:
I wrote:
Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew
This too.
Uh, no, actually it isn't. I thought we were going to make cases
like "" be treated as XML tags, but CVS HEAD fails to do that:
regression=# select * from ts_debug('foo');
alia
On Sat, 24 Nov 2007, Guillaume Smet wrote:
Here are some rough results:
http://people.openwide.fr/~gsmet/postgresql/postgresql_8.3_development_cycle_1.png
So the big dips were Jan->Feb and April->May. I've still got the text of
the commit log Tom assembled sitting at
http://developer.postgr
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Here are some rough results:
> http://people.openwide.fr/~gsmet/postgresql/postgresql_8.3_development_cycle_1.png
I repeated this experiment using the "pgbench -n -S -c 10 -t 10 bench"
test case that I've been looking at. The attached graph shows
29 matches
Mail list logo
