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
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 r
On Sat, May 1, 2010 at 8:25 PM, 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 usin
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:
http://www.castleproject.or
On Sat, May 1, 2010 at 8:12 PM, Craig Ringer
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 costs of a MSSQL installatio
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, bac
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 th
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
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 p
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
enjoye
Tom Lane wrote:
Greg Smith 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 few commit messages
m
2010/4/30 Mike Christensen :
> 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 the only thing
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
di
On Sat, May 1, 2010 at 2:47 PM, 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 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_ better/fa
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, May 1, 2010 at 12:47 PM, 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 Sat, May 1, 2010 at 12:09 PM, Lew 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 of those claims is
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
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 Ope
On Sat, May 1, 2010 at 9:27 AM, Tom Lane 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 it triggers a
Greg Smith 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 2009 (rele
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
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
2010/5/1 John R Pierce :
> 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
On Fri, Apr 30, 2010 at 11:33 PM, Scott Marlowe wrote:
> On Fri, Apr 30, 2010 at 9:02 PM, Greg Smith 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 s
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
figu
On Fri, Apr 30, 2010 at 9:02 PM, Greg Smith 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
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
2010/5/1 Greg Smith :
> 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
2010/5/1 Devrim GÜNDÜZ :
> 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 wa
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
On Sat, May 1, 2010 at 12:59 AM, Greg Smith 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 hold.
>
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
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 ha
35 matches
Mail list logo
