Re: IBM/DB2 PostgreSQL FUD? - Mailing list pgsql-advocacy

On Tue, 2004-07-13 at 03:47, Simon Riggs wrote:

> I note for example, that MySQL still have a benchmark page up that says
> something like "but we couldn't run PostgreSQL because VACUUM had a
> bug". Those things may be true, maybe not, but they are clearly both on
> significantly older releases and so both can and should be ignored. They
> can't be unsaid and arguing about it just makes you dance to their tune.

FYI, I think they dropped this page a while back (I can't find it in
their docs online).

But, they still list our maximum query size as 16 Megs, as that's the
size of the buffer they declare to test with, and when it errors out at
16 Meg, they say that's our query limit.

Of course, for quite some time now PostgreSQL has had no query size
limit, only the one imposed by the hardware you're able to buy or with
an unlimited budget, the largest machine made.

They've been informed of this error, by me, on at least one occasion.
They have not changed it. [1]

> Most importantly, PostgreSQL users should be confident that if IBM is
> saying bad things about PostgreSQL, its clearly on their radar - always
> the best compliment. That means we're not far off having some IBM
> staffers contributing regularly to the project...

Good point.

[1]  More things they get wrong, that I've told them about in the past,
that they haven't changed:

The max buffer of 16 Meg affects a few other fields that they test
(constant string size in SELECT and constant string size in where) which
again has a limit of probably 1 gig right now.)
Max table row length: 103279 (Actually 2 gig per field, several hundred
fields at least, but they use the max length of char() for this?  Not
text?  And only one field to test it?)
It lists updates as non-atomic, although with select for update,
PostgreSQL updates are fully atomic.
It lists type for row id as oid, when serial would be more correct.
They test for max and or with this query:
select a from crash_me where a=1 and b='a'  or a=0 and b='0' or a=1 and
b='1' or a=2 and b='2' or a=3 and b='3' or a=4 and b='4'
Notice any problem with the uselessness of the logic, at least test with
something useful.
They list the maximum number of arguments at 9999 with no footnote that
this value is user settable via expression depth, the HINT tells you so.
Maximum text listed as >8 meg, when in fact it's 128k times 8 meg as the
max, typically (i.e. 1 gig)

Of course most of this isn't malice, it's just not being familiar enough
with PostgreSQL to know these things.  I've pointed out these errors in
the past, and gotten nary a peep for a response.  Maybe I should try
again.