2010/5/1 Greg Smith g...@2ndquadrant.com:
Vincenzo Romano wrote:
I argued that O(n) stuff will keep it away from enterprise grade
applications.
I've been told earlier that It is fine for dozens of child tables,
but not thousands;
it does need improvement.
This is not enterprise grade
Scott Marlowe wrote:
I tested 8.4 what I thought was fairly hardly last year only
to have 8.4.1 die under the same load that 8.3 handled without a
problem, and reverted to the known working version putting testing
8.4.1 on hold.
So to ME, the choice is a fully functional 8.3 installation that
Vincenzo Romano wrote:
While I can agree that Enterprise grade is a buzzword, it does mean
something: very large amount of data among other.
http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
It's quite straighforward to get PostgreSQL up and running with many
terabytes of
On Sat, May 1, 2010 at 12:59 AM, Greg Smith g...@2ndquadrant.com wrote:
Scott Marlowe wrote:
I tested 8.4 what I thought was fairly hardly last year only
to have 8.4.1 die under the same load that 8.3 handled without a
problem, and reverted to the known working version putting testing
8.4.1
On Sat, 2010-05-01 at 02:59 -0400, Greg Smith wrote:
FYI, since December of 2009 (release of 8.4.2) there have been 10 bugs
fixed with the word crash in their description, as well as 7 memory
leaks that could potentially lead to crash. Even six months ago I was
still hesitant to push 8.4
2010/5/1 Devrim GÜNDÜZ dev...@gunduz.org:
On Sat, 2010-05-01 at 02:59 -0400, Greg Smith wrote:
FYI, since December of 2009 (release of 8.4.2) there have been 10 bugs
fixed with the word crash in their description, as well as 7 memory
leaks that could potentially lead to crash. Even six months
2010/5/1 Greg Smith g...@2ndquadrant.com:
Vincenzo Romano wrote:
While I can agree that Enterprise grade is a buzzword, it does mean
something: very large amount of data among other.
http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
It's quite straighforward to get
Greg Smith wrote:
Enterprise grade doesn't mean anything. Partitioning designs that
require thousands of child tables to work right are fundamentally
misdesigned anyway, so there is no reason for any of the contributors
to the project to work on improving support for them. There are far
too
On Fri, Apr 30, 2010 at 9:02 PM, Greg Smith g...@2ndquadrant.com wrote:
Joshua D. Drake wrote:
On Fri, 2010-04-30 at 13:42 -0700, Gauthier, Dave wrote:
If I had to plan server deployments for the next year (and I do) I'd
be sticking with pg 8.3 and a proven replication engine. Next summer
On 30/04/2010 5:33 PM, Kenichiro Tanaka wrote:
Hi
The hyphen which written in 'Olympus E-PL1' is different from
the one which written in 'Camera - Black'.
em-dash
http://www.fileformat.info/info/unicode/char/2014/index.htm
en-dash
http://www.fileformat.info/info/unicode/char/2013/index.htm
On Fri, Apr 30, 2010 at 11:33 PM, Scott Marlowe scott.marl...@gmail.com wrote:
On Fri, Apr 30, 2010 at 9:02 PM, Greg Smith g...@2ndquadrant.com wrote:
Joshua D. Drake wrote:
On Fri, 2010-04-30 at 13:42 -0700, Gauthier, Dave wrote:
If I had to plan server deployments for the next year (and I
2010/5/1 John R Pierce pie...@hogranch.com:
Greg Smith wrote:
Enterprise grade doesn't mean anything. Partitioning designs that require
thousands of child tables to work right are fundamentally misdesigned
anyway, so there is no reason for any of the contributors to the project to
work on
On 1 May 2010, at 5:33, John R Pierce wrote:
Greg Smith wrote:
my sql developer, who's been doing oracle for 15+ years, says postgres'
partitioning is flawed from his perspective because if you have a prepared
statement like..
SELECT fields FROM partitioned_table WHERE primarykey = $1;
On 1 May 2010, at 12:56, Alban Hertroys wrote:
You could argue that some logic could be added to the handling of prepared
statements to insert query-subplans depending on what data you use for your
parameters, but then you're moving back in the direction of unprepared
statements (namely
Greg Smith g...@2ndquadrant.com writes:
Scott Marlowe wrote:
I tested 8.4 what I thought was fairly hardly last year only
to have 8.4.1 die under the same load that 8.3 handled without a
problem, and reverted to the known working version putting testing
8.4.1 on hold.
FYI, since December of
On Sat, May 1, 2010 at 9:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm curious to get to the bottom of Scott's report. It's possible that
he hit one of the two or three 8.4-only crashes we fixed since 8.4.1;
or the bug may still be lurking.
I'll definitely be testing it this summer to see if
Philippe Lang wrote:
I think nobody mentioned Object-Relational mappers.
If you intend to used one (or think you may be using one in the future),
using surrogate keys is more straightforward, if not necessary.
Neither of those claims is even slightly true. Using Hibernate, EclipseLink
or
Anybody know of any recent comparisons made between the two?
I'm in the process of buying a new telephony related software suite,
and I'm getting mixed advice. Some say that MSSQL is _much_
better/faster than PostgreSQL, and others say the opposite.
The vendor is more or less indifferent, with a
On Sat, May 1, 2010 at 12:09 PM, Lew no...@lwsc.ehost-services.com wrote:
Philippe Lang wrote:
I think nobody mentioned Object-Relational mappers.
If you intend to used one (or think you may be using one in the future),
using surrogate keys is more straightforward, if not necessary.
Neither
On Sat, May 1, 2010 at 12:47 PM, Thomas Løcke thomas.granv...@gmail.com wrote:
Anybody know of any recent comparisons made between the two?
I'm in the process of buying a new telephony related software suite,
and I'm getting mixed advice. Some say that MSSQL is _much_
better/faster than
If your 'natural key' is a large text field, I'd have to assume there's
some point at which a surrogate index would be more efficient. Would
this be above a few dozen characters, or a few 100 characters? I
wouldn't want a PK based on a multi-K byte text field for a table that
has many 10s
On Sat, 1 May 2010, Thomas Løcke wrote:
Anybody know of any recent comparisons made between the two?
A Google search will turn up a lot of comparisons.
I'm in the process of buying a new telephony related software suite, and
I'm getting mixed advice. Some say that MSSQL is _much_
On Sat, May 1, 2010 at 2:47 PM, Thomas Løcke thomas.granv...@gmail.com wrote:
Anybody know of any recent comparisons made between the two?
I'm in the process of buying a new telephony related software suite,
and I'm getting mixed advice. Some say that MSSQL is _much_
better/faster than
Thomas Løcke wrote:
Anybody know of any recent comparisons made between the two?
for purely SQL, I prefer Postgres by a wide margin.But, MS SQL
Server comes with a whole infrastructure that includes a lot of powerful
tools, like replication, data extraction and translation, active
2010/4/30 Mike Christensen m...@kitchenpc.com:
Ok I've been blatantly lying, err, purposely simplifying the problem for the
sake of the original email :)
I've read over the responses, and am actually now considering just not using
any index at all. Here's why:
First, this actually isn't
Tom Lane wrote:
Greg Smith g...@2ndquadrant.com writes:
FYI, since December of 2009 (release of 8.4.2) there have been 10 bugs
fixed with the word crash in their description, as well as 7 memory
leaks that could potentially lead to crash.
Are we reading the same CVS log? I find quite a
On May 1, 2010, at 12:47 PM, Thomas Løcke wrote:
The
sales-people all bang on about MSSQL being the superior choice, and
PostgreSQL being a toy compared to the Microsoft RDBMS.
This is complete bullshit.
I say that as someone who spent years using MS SQL Server, and who very much
enjoyed
Scott Ribe wrote:
PG's locking scheme, MVCC, basically precludes certain specific optimizations
that means a small number of very specific queries don't perform as well, while
at the same time it means that throughput with multiple simultaneous
connections scales extremely well with multiple
On May 1, 2010, at 5:16 PM, Greg Smith wrote:
SQL Server uses MVCC too as of their 2005 release, implemented with row
versioning similarly to Postgres. The main non-MVCC holdout at this point is
DB2.
Funny, I've ported to even later versions than that, but missed the change.
Well, OK, I'm
On Sat, 2010-05-01 at 20:47 +0200, Thomas Løcke wrote:
--Anybody know of any recent comparisons made between the two?
I'm in the process of buying a new telephony related software suite,
and I'm getting mixed advice. Some say that MSSQL is _much_
better/faster than PostgreSQL, and others say
On 02/05/10 02:47, Thomas Løcke wrote:
I've not been able to convince them to send me some actual benchmark
numbers, which actually should turn on quite a few alarms, come to
think about it. :o)
Is performance really your #1 criterion anyway?
I'd be looking at management, reliability,
On Sat, May 1, 2010 at 8:12 PM, Craig Ringer
cr...@postnewspapers.com.au wrote:
I'd be looking at management, reliability, backup, integration into the
rest of the infrastructure, product longevity, support, etc. Performance
you can always throw hardware at.
And given the relatively high
I have a table that stores a user ID and a subscription type, and this is
really all it needs to store and any pair of values will always be unique.
In fact, I think this pair should be the primary key on the table. However,
I'm using Castle ActiveRecord which says at:
On Sat, May 1, 2010 at 8:25 PM, Mike Christensen m...@kitchenpc.com wrote:
I have a table that stores a user ID and a subscription type, and this is
really all it needs to store and any pair of values will always be unique.
In fact, I think this pair should be the primary key on the table.
On May 1, 2010, at 7:25 PM, Mike Christensen wrote:
\And I quote:
Quick Note: Composite keys are highly discouraged. Use only when you
have no other alternative.
I get the feeling they're discouraged from a SQL point of view, but
it doesn't actually say why anywhere. Is there any good
On Sat, 2010-05-01 at 19:25 -0700, Mike Christensen wrote:
--I have a table that stores a user ID and a subscription type, and this
is really all it needs to store and any pair of values will always be unique.
In fact, I think this pair should be the primary key on the table. However, I'm
36 matches
Mail list logo
