Did the FAA ever publish slides of those talks? Sure wish I could see them... :)
P.
On 2010-08-11, at 6:58 PM, Bruce Momjian wrote:
> Greg Smith wrote:
>> Greg Williamson wrote:
>>> Our tests -- very much oriented at postGIS found Oracle to be between 5
>>> and 15% _faster_ depending on the spe
Paul Ramsey wrote:
> Did the FAA ever publish slides of those talks? Sure wish I could see them...
> :)
No, sorry, I don't think I ever saw the slides published.
---
>
> P.
>
> On 2010-08-11, at 6:58 PM, Bruce Momjian w
Greg Smith wrote:
> Tom Lane wrote:
> > I'm sure EnterpriseDB or one of the other PG support companies
> > would be happy to sell you a support contract, if having somebody to sue
> > is an essential part of happiness.
> >
>
> And on a good day, access to someone with the source code who will
Greg Smith wrote:
> Greg Williamson wrote:
> > Our tests -- very much oriented at postGIS found Oracle to be between 5
> > and 15% _faster_ depending on the specifics of the task. We decided to go
> > with postgres given the price difference (several hundred thousand dollars
> > for
> > Oracle in
Tom Lane wrote:
I'm sure EnterpriseDB or one of the other PG support companies
would be happy to sell you a support contract, if having somebody to sue
is an essential part of happiness.
And on a good day, access to someone with the source code who will
actually be motivated to fix your pro
On Thu, Jul 29, 2010 at 8:04 PM, Scott Marlowe wrote:
> $50k or so you can throw 100 hard drives at the problem.
Or even one of these: http://www.ramsan.com/products/ramsan-620.asp :-)
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
ht
Howard Rogers writes:
> Sadly, I won't be able to provide much further analysis or
> information, because the box concerned is being wiped. The MD decided
> that, as a matter of corporate governance, he couldn't punt the
> company on PostgreSQL, so my experimenting days are over. Back to
> Oracle:
On 30 July 2010 00:38, Howard Rogers wrote:
> I can't see any change to the sorting behaviour there. Work_mem was
> set to 4096MB, shared buffers to 12228MB, temp_buffers to 1024MB,
> effective_cache_size to 18442MB.
>
Ah yes. The sorting idea was a complete red herring. The top-N
heapsort to pic
On Thu, Jul 29, 2010 at 10:33 PM, Dean Rasheed wrote:
> On 28 July 2010 02:58, Howard Rogers wrote:
>> For what it's worth, I wrote up the performance comparison here:
>> http://diznix.com/dizwell/archives/153
>>
>
> Thanks, very interesting results. I wonder, are the results being
> sorted by th
On Thu, Jul 29, 2010 at 5:42 PM, Greg Smith wrote:
> Greg Williamson wrote:
>>
>> Our tests -- very much oriented at postGIS found Oracle to be between 5
>> and 15% _faster_ depending on the specifics of the task. We decided to go
>> with postgres given the price difference (several hundred thousa
Greg Williamson wrote:
Our tests -- very much oriented at postGIS found Oracle to be between 5
and 15% _faster_ depending on the specifics of the task. We decided to go
with postgres given the price difference (several hundred thousand dollars for
Oracle in the configuration we needed vs. zip for
On 28 July 2010 02:58, Howard Rogers wrote:
> For what it's worth, I wrote up the performance comparison here:
> http://diznix.com/dizwell/archives/153
>
Thanks, very interesting results. I wonder, are the results being
sorted by the database? The performance degradation for large numbers
of resu
Greg Williamson wrote:
Our tests -- very much oriented at postGIS found Oracle to be between 5
and 15% _faster_ depending on the specifics of the task. We decided to go
with postgres given the price difference (several hundred thousand dollars for
Oracle in the configuration we needed vs. zip fo
On 28/07/10 02:58, Howard Rogers wrote:
For what it's worth, I wrote up the performance comparison here:
http://diznix.com/dizwell/archives/153
Thanks very much Howard.
It might be my schoolboy-physics ability to fit a curve to two data
points, but does anyone else think that the second and t
On Wed, Jul 28, 2010 at 8:38 PM, Daniel Verite wrote:
> zhong ming wu wrote:
>
>> I always thought there is a clause in their user agreement preventing
>> the users from publishing benchmarks like that. I must be mistaken.
>
> No you're correct. Currently, to download the current Oracle 11.
Thomas Kellerer writes:
> Howard Rogers, 28.07.2010 03:58:
>> For what it's worth, I wrote up the performance comparison here:
>> http://diznix.com/dizwell/archives/153
> Very interesting reading.
Indeed.
> Would you mind sharing the tables, index structures and search queries that
> you used
On Tue, 27 Jul 2010 23:24:12 -0600, Scott Marlowe
wrote:
>
> Someone running Oracle is complaining about training costs? That
> seems a bit like complaining about needing to give the bellboy a $1
> tip at a $1k a night hotel.
Depending on how they are running their licensing,
(user/processor/s
zhong ming wu wrote:
> I always thought there is a clause in their user agreement preventing
> the users from publishing benchmarks like that. I must be mistaken.
No you're correct. Currently, to download the current Oracle 11.2g, one must
agree to:
http://www.oracle.com/technetwork/licen
zhong ming wu wrote:
>
> On Tue, Jul 27, 2010 at 9:58 PM, Howard Rogers wrote:
>
> > For what it's worth, I wrote up the performance comparison here:
> > http://diznix.com/dizwell/archives/153
>
> I always thought there is a clause in their user agreement preventing
> the users from publishi
On Tue, Jul 27, 2010 at 9:58 PM, Howard Rogers wrote:
> Thanks to some very helpful input here in earlier threads, I was
> finally able to pull together a working prototype Full Text Search
> 'engine' on PostgreSQL and compare it directly to the way the
> production Oracle Text works. The good new
Howard,
that was a great read!
I especially like your sentence
""" Considering that any search containing more than a half-dozen
search terms is more like an essay than a realistic search; and
considering that returning half a million matches is more a data dump
than a sensible search facility,"
2010/7/28 Thomas Kellerer :
> Why is it that managers always see short term savings but fail to see
> longterm expenses?
It's all about CAPEX vs OPEX, baby!
Besides jokes, it's actually myopia.
Because they ALREADY spent money for training they don't see the need
for extra training (and costs), as
Howard Rogers, 28.07.2010 03:58:
Thanks to some very helpful input here in earlier threads, I was
finally able to pull together a working prototype Full Text Search
'engine' on PostgreSQL and compare it directly to the way the
production Oracle Text works. The good news is that PostgreSQL is
bloo
On Tue, Jul 27, 2010 at 7:58 PM, Howard Rogers wrote:
> Thanks to some very helpful input here in earlier threads, I was
> finally able to pull together a working prototype Full Text Search
> 'engine' on PostgreSQL and compare it directly to the way the
> production Oracle Text works. The good new
24 matches
Mail list logo
