> That isn't really an extensibility argument. At least not in my mind.
> Further I don't know of anyone that can "easily" do it. You either
> suffer the possibility of catastrophic data loss (dolphins) or you
> suffer guaranteed bank account drainage (Oracle), or you suffer the
> willingness of Monopolies (MSSQL).
>
> None of those equate to "easy".

That's a load of FUD. When looking at feature-sets that are available or not
available in an open source product, you can't throw out all the things that a
commercial, closed source project has because it isn't open source and it costs
money.

The reason companies go with the closed source, expensive solutions is because
they are better products.

When evaluating a database for your company, it is better to look at what the
closed source products offer that cause companies to shell out tons of money and
decide if it is worth locking yourself into an expensive and/or exclusive agreement.

Guido Neitzer wrote:
> On 08.01.2008, at 23:20, Joshua D. Drake wrote:
>
>> That isn't really an extensibility argument.
>
> I was thinking about that too - for me, it still is just an outstanding
> issue with PostgreSQL. It is incredibly scalable on one machine but it
> totally sucks when you want more, but not much more.

There are OS level things you can do here.


> But if you need something easy to setup, multi-master with just two
> machines, easy fail-over (done in the JDBC driver) without your
> application even noticing it - try it.

http://www.continuent.org/HomePage


> It's free, but not open source.
> And it's a good product. I use it for some stuff and PostgreSQL for
> other projects. Just depends on the requirements.
>

Sincerely,

Joshua D. Drake



> cug
>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 08.01.2008, at 23:40, Joshua D. Drake wrote:

> There are OS level things you can do here.

They are normally not really easier and, more important, I don't have
them on my deployment environment.

> http://www.continuent.org/HomePage

When I'm talking about two cheap machines you recommend a solution
where I need four machines (Or can I use the uni/cluster machines also
as db nodes?) and licenses for a couple of thousands bucks? Sorry, no
option.

And, I have my option ...

cug

--
http://www.event-s.net


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Sim Zacks wrote:
>
> > That isn't really an extensibility argument. At least not in my mind.
> > Further I don't know of anyone that can "easily" do it. You either
> > suffer the possibility of catastrophic data loss (dolphins) or you
> > suffer guaranteed bank account drainage (Oracle), or you suffer the
> > willingness of Monopolies (MSSQL).
> >
> > None of those equate to "easy".
>
> That's a load of FUD. When looking at feature-sets that are available or
> not
> available in an open source product, you can't throw out all the things
> that a
> commercial, closed source project has because it isn't open source and
> it costs
> money.

You obviously didn't read my post.

>
> The reason companies go with the closed source, expensive solutions is
> because
> they are better products.

Sometimes, sometimes not. It depends on your needs.

>
> When evaluating a database for your company, it is better to look at
> what the
> closed source products offer that cause companies to shell out tons of
> money and
> decide if it is worth locking yourself into an expensive and/or
> exclusive agreement.

The only thing this post could possibly be is a Troll. Please go back
under the bridge.

Sincerely,

Joshua D. rake



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Guido Neitzer wrote:
> On 08.01.2008, at 23:40, Joshua D. Drake wrote:
>
>> There are OS level things you can do here.
>
> They are normally not really easier and, more important, I don't have
> them on my deployment environment.
>
>> http://www.continuent.org/HomePage
>
> When I'm talking about two cheap machines you recommend a solution where
> I need four machines (Or can I use the uni/cluster machines also as db
> nodes?) and licenses for a couple of thousands bucks? Sorry, no option.
>

Did you even bother to read the page?

http://sequoia.continuent.org/HomePage

Open Source... Free...

Sequoia is a transparent middleware solution offering clustering, load
balancing and failover services for any database. Sequoia is the
continuation of the C-JDBC project.

It can be downloaded here:

https://forge.continuent.org/frs/?group_id=6


> And, I have my option ...
>

Great! I was just trying to show you that there was a JDBC layer
available for multi-mastering with PostgreSQL.

Sincerely,

Joshua D. Drake



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Tue, 2008-01-08 at 23:37 -0700, Guido Neitzer wrote:
> On 08.01.2008, at 23:20, Joshua D. Drake wrote:

> Like, I have a situation where I need multi-master just for
> availability. Two small servers are good enough for that. But
> unfortunately with PostgreSQL the whole setup is a major pain in the ...
>

Isn't that the reason they hire DB admins and not the run of the mill
guy.

I've not played with multimaster (sync/async) and I doubt I will since
there's no requirement for it., (yet)

In any case, based on my research there's lots of FOSS and (not-so)FOSS
based solutions and of course, each comes with their own learning curve
and also depends on the complexity of the requirements. (Mind you, even
MSSQL with all it's polished point and click interface, you still have
times when you pull hairs out)

I've done a simple master/slave configuration which is faring well, so
that's fine (for me)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Tue, 2008-01-08 at 23:05 -0800, Joshua D. Drake wrote:
> Sim Zacks wrote:

>
> >
> > The reason companies go with the closed source, expensive solutions is
> > because they are better products.
>
> Sometimes, sometimes not. It depends on your needs.

This is total FUD. Everything has a place. And besides, as what I read, nobody ever gets fired
for recommending an expensive solution that comes with expensive support contracts and what not.
(wish I could google and insert the link to where I read that)

>
> >
> > When evaluating a database for your company, it is better to look at
> > what the
> > closed source products offer that cause companies to shell out tons of
> > money and
> > decide if it is worth locking yourself into an expensive and/or
> > exclusive agreement.
>
> The only thing this post could possibly be is a Troll. Please go back
> under the bridge.


No, it's better to evaluate if the features which are being provided
will fit your needs. This is akin to buying a lamborghini only to drive
it down to the local 7-11, down the (same) road to buy some bread.

Take a walk instead, save my ears, save some petrol, save some money.

Otherwise, you end up paying X amount more for features you don't need.
(Me remembers vividly an episode of Simpsons where Homer was given free
rein to design the ultimate American Dream Car.)


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

You wrote that either it is not implemented well (catastrophic data losss) or is
expensive (Oracle) or it is a monopoly (MSSQL). None of those are easy.
Expensive and monopoly don't seem to me to be non-easy, rather undesirable if
you don't need to get into it.

When someone asks a question about a feature found in a commercial product and
the answer is that the feature is not available unless you accept on yourself
horrid possibilities, that is similar to Microsoft saying that sure you can use
open source, but there is no support, it is unreliable, ... Pure FUD. You can
call it reverse FUD, but it is FUD nonetheless.

We use postgresql because it is open source, we have in-house experience to deal
with it so we don't have any extra support costs and we don't need the features
that are offered in commercial products that PostGreSQL does not have. We also
don't need the speed that commercial products offer that is missing in PostgreSQL.

Sim


Joshua D. Drake wrote:
> Sim Zacks wrote:
>>
>> > That isn't really an extensibility argument. At least not in my mind.
>> > Further I don't know of anyone that can "easily" do it. You either
>> > suffer the possibility of catastrophic data loss (dolphins) or you
>> > suffer guaranteed bank account drainage (Oracle), or you suffer the
>> > willingness of Monopolies (MSSQL).
>> >
>> > None of those equate to "easy".
>>
>> That's a load of FUD. When looking at feature-sets that are available
>> or not
>> available in an open source product, you can't throw out all the
>> things that a
>> commercial, closed source project has because it isn't open source and
>> it costs
>> money.
>
> You obviously didn't read my post.
>
>>
>> The reason companies go with the closed source, expensive solutions is
>> because
>> they are better products.
>
> Sometimes, sometimes not. It depends on your needs.
>
>>
>> When evaluating a database for your company, it is better to look at
>> what the
>> closed source products offer that cause companies to shell out tons of
>> money and
>> decide if it is worth locking yourself into an expensive and/or
>> exclusive agreement.
>
> The only thing this post could possibly be is a Troll. Please go back
> under the bridge.
>
> Sincerely,
>
> Joshua D. rake
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

On Wed, 2008-01-09 at 00:24 -0700, Guido Neitzer wrote:
> On 09.01.2008, at 00:14, Ow Mun Heng wrote:
>
> >> Like, I have a situation where I need multi-master just for
> >> availability. Two small servers are good enough for that. But
> >> unfortunately with PostgreSQL the whole setup is a major pain in
> >> the ...
> >>
> >
> > Isn't that the reason they hire DB admins and not the run of the mill
> > guy.
>
> Isn't that more the situation where it is preferred to have a working
> fail-over with as less money and work as possible?

Yep.. There's where FOSS comes about. But as mentioned, there's a
learning curve in everything and granted that in FOSS, sometimes
documentation is sparse etc.

I guess the other side of the coin is this -> If you want it cheap, you
have to do it yourself and I've be rich for each time the
plumber/electricion/etc comes around to fix something. Each time, the
itch is for me to learn how to do it myself.

>
> There is just no way I (personally) can afford hiring someone to set
> that up as I'm talking about something that hasn't brought a dollar
> yet and will probably not for the next time ... and it is my own
> project, but there is still some need for a reliable service to come
> to a point where I can maybe hire someone.

point taken.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Ow Mun Heng wrote:
> On Tue, 2008-01-08 at 23:05 -0800, Joshua D. Drake wrote:
>> Sim Zacks wrote:
>
>>> The reason companies go with the closed source, expensive solutions is
>>> because they are better products.
>> Sometimes, sometimes not. It depends on your needs.
>
> This is total FUD. Everything has a place. And besides, as what I read, nobody ever gets fired
> for recommending an expensive solution that comes with expensive support contracts and what not.
> (wish I could google and insert the link to where I read that)

Exactly. It is amazing to me that companies are snookered into the idea
that per cpu pricing (or per client) for support contracts is a valid
method to determine actual costs to support the customer.

There are good closed source products but to suggest that just because
it is an expensive solution it is better is a little dumb.


>> The only thing this post could possibly be is a Troll. Please go back
>> under the bridge.
>
> No, it's better to evaluate if the features which are being provided
> will fit your needs. This is akin to buying a lamborghini only to drive
> it down to the local 7-11, down the (same) road to buy some bread.
>
> Take a walk instead, save my ears, save some petrol, save some money.

No kidding.

>
> Otherwise, you end up paying X amount more for features you don't need.
> (Me remembers vividly an episode of Simpsons where Homer was given free
> rein to design the ultimate American Dream Car.)
>

Heh...

Sincerely,

Joshua D. Drake



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings