Обсуждение: Re: Re: MySQL has transactions

Поиск
Список
Период
Сортировка

Re: Re: MySQL has transactions

От
"Mitch Vincent"
Дата:
> When Postgresql 6.5 came out it, it was VERY MUCH better ( many many
thanks
> to the developers and all involved). And I'm waiting for a solid 7.1 to
fix
> that <8KB issue.

Technically..

<= BLCKSZ (can be up to  32k)

I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions
server) and haven't had a problem one..

-Mitch




Re: Re: MySQL has transactions

От
Lincoln Yeoh
Дата:
At 10:02 AM 1/25/01 -0500, you wrote:
>> When Postgresql 6.5 came out it, it was VERY MUCH better ( many many
>thanks
>> to the developers and all involved). And I'm waiting for a solid 7.1 to
>fix
>> that <8KB issue.
>
>Technically..
>
><= BLCKSZ (can be up to  32k)
>
>I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions
>server) and haven't had a problem one..

Yep but doesn't quite help my webmail app :). 

I'm wondering if TOAST is going to be efficient enough for me to plonk
multimegabyte email attachments into the database. 

However I've also a suspicion that there might be problems doing

INSERT INTO mytable (a) values ( 'aa.......');

Where aa... is a few megabytes long :). There's probably a query size limit
somewhere between my app and TOAST. 

Cheerio,
Link.



Re: Re: Re: MySQL has transactions

От
Tom Lane
Дата:
Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> I'm wondering if TOAST is going to be efficient enough for me to plonk
> multimegabyte email attachments into the database. 

Should work.  The main limitation on TOAST is that it wants to treat
each datum as a unit, ie you must fetch or store the whole value in one
go.  When your datums get big enough that that's inconvenient, you won't
like TOAST so much.  I don't foresee it being a big issue for emailable
items though ...

> However I've also a suspicion that there might be problems doing

> INSERT INTO mytable (a) values ( 'aa.......');

> Where aa... is a few megabytes long :). There's probably a query size limit
> somewhere between my app and TOAST. 

I've tested this, it works fine since 7.0 or so.

Amusing anecdote: since 7.0, MySQL's "crashme" test crashes when run
against Postgres.  Postgres is fine, it's the perl job running the
crashme script that goes belly-up.  It seems that crashme's loop that
tries to discover the maximum query length is more memory-hungry than
Postgres itself, and so the perl job hits the kernel-imposed maximum
process size before the backend does.  Moral: before assuming Postgres
can't do something, make sure your own code can hold up its end...
        regards, tom lane