text field

[rkusenet]

IDS 9.21.

We are in the process of making a change in a heavy insert table.
This table gets lot of inserts. A row , after getting inserted,
is read and updated for next few minutes by another process. After
that the row has no utility left and is deleted at the end of the
day.

One of the columns in the table is a VARCHAR column. This column
now will store additional information which can run upto 20K in
length. This means both VARCHAR and LVARCHAR can not store that
size of information. My main concern is the performance penalty
during insert if the column is changed to a text field. Which is
the best way to store this field. TEXT in TABLE or TEXT in
blobspace. I know that TEXT in blobspace bypasses buffers. So that
would mean that every insert will result in more disk write.
OTOH text in table may consume lot of buffers, even though it
will avoid immediate disk write.

TIA.

[Mark D. Stock]

rkusenet wrote:

> IDS 9.21.
>
> We are in the process of making a change in a heavy insert table.
> This table gets lot of inserts. A row , after getting inserted,
> is read and updated for next few minutes by another process. After
> that the row has no utility left and is deleted at the end of the
> day.
>
> One of the columns in the table is a VARCHAR column. This column
> now will store additional information which can run upto 20K in
> length. This means both VARCHAR and LVARCHAR can not store that
> size of information. My main concern is the performance penalty
> during insert if the column is changed to a text field.

Why not use a CHAR?

Cheers,
--
Mark.

+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
| Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
| +-----------------------------------+//// / ///|
| |We value your comments, which have |/// / ////|
| |been recorded and automatically |// / /////|
| |emailed back to us for our records.|/ ////////|
+----------------------+-----------------------------------+-----------+

sending to informix-list

[rkusenet]

"Mark D. Stock" <mdstock@mydassolutions.com> wrote in message
news:bksvi3$48s$1@terabinaries.xmission.com...

>
> rkusenet wrote:
>

> > IDS 9.21.
> >
> > We are in the process of making a change in a heavy insert table.
> > This table gets lot of inserts. A row , after getting inserted,
> > is read and updated for next few minutes by another process. After
> > that the row has no utility left and is deleted at the end of the
> > day.
> >
> > One of the columns in the table is a VARCHAR column. This column
> > now will store additional information which can run upto 20K in
> > length. This means both VARCHAR and LVARCHAR can not store that
> > size of information. My main concern is the performance penalty
> > during insert if the column is changed to a text field.

>
> Why not use a CHAR?

A char field of 20000 length???

[Colin Bull]

rkusenet wrote

>
> We are in the process of making a change in a heavy insert table.
> This table gets lot of inserts. A row , after getting inserted,
> is read and updated for next few minutes by another process. After
> that the row has no utility left and is deleted at the end of the
> day.
>
> One of the columns in the table is a VARCHAR column. This column
> now will store additional information which can run upto 20K in
> length. This means both VARCHAR and LVARCHAR can not store that
> size of information. My main concern is the performance penalty
> during insert if the column is changed to a text field. Which is
> the best way to store this field. TEXT in TABLE or TEXT in
> blobspace. I know that TEXT in blobspace bypasses buffers. So that
> would mean that every insert will result in more disk write.
> OTOH text in table may consume lot of buffers, even though it
> will avoid immediate disk write.
>

Lvarchar in 9.4 are up to 32k. Might be a better option than text fields and
blobspaces.

Colin Bull
[email]c.bull@videonetworks.com[/email]

sending to informix-list

[Mark D. Stock]

rkusenet wrote:

> "Mark D. Stock" <mdstock@mydassolutions.com> wrote in message
> news:bksvi3$48s$1@terabinaries.xmission.com...
>

>>rkusenet wrote:
>>
>>

>>>IDS 9.21.
>>>
>>>We are in the process of making a change in a heavy insert table.
>>>This table gets lot of inserts. A row , after getting inserted,
>>>is read and updated for next few minutes by another process. After
>>>that the row has no utility left and is deleted at the end of the
>>>day.
>>>
>>>One of the columns in the table is a VARCHAR column. This column
>>>now will store additional information which can run upto 20K in
>>>length. This means both VARCHAR and LVARCHAR can not store that
>>>size of information. My main concern is the performance penalty
>>>during insert if the column is changed to a text field.

>>
>>Why not use a CHAR?

>
>
> A char field of 20000 length???

You can go up to CHAR(32767) if you want. It will just be fixed length,
that's all, but possibly easier to use than TEXT.

As Colin says, you can use LVARCHAR of similar size in IDS version 9.40.
However, in reality it is up to LVARCHAR(32739).

Cheers,
--
Mark.

+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
| Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
| +-----------------------------------+//// / ///|
| |We value your comments, which have |/// / ////|
| |been recorded and automatically |// / /////|
| |emailed back to us for our records.|/ ////////|
+----------------------+-----------------------------------+-----------+

sending to informix-list

[rkusenet]

"Mark D. Stock" <mdstock@mydassolutions.com> wrote

> >
> > A char field of 20000 length???

>
> You can go up to CHAR(32767) if you want. It will just be fixed length,
> that's all, but possibly easier to use than TEXT.

I know that CHAR can go up to 32K. I want to know whether it makes
sense to have such a huge char field. It will fill out the buffers,
logical logs rapidly.

May be I will have to compare the speed of char(32K) with a text
field in rapid inserts.

Ravi.

[Art S. Kagel]

On Wed, 24 Sep 2003 13:21:03 -0400, rkusenet wrote:

I'd create a child table with a foreign key to the original table with CASCADE
DELETE enabled. The child has the original table's key, a sequence number, and
a reasonably sized CHAR column. Break the large text into multiple rows
inserted into the child table. Clean, neat, storage efficient, easily
implemented, and even portable.

Art S. Kagel

> IDS 9.21.
>
> We are in the process of making a change in a heavy insert table. This table
> gets lot of inserts. A row , after getting inserted, is read and updated for
> next few minutes by another process. After that the row has no utility left
> and is deleted at the end of the day.
>
> One of the columns in the table is a VARCHAR column. This column now will
> store additional information which can run upto 20K in length. This means both
> VARCHAR and LVARCHAR can not store that size of information. My main concern
> is the performance penalty during insert if the column is changed to a text
> field. Which is the best way to store this field. TEXT in TABLE or TEXT in
> blobspace. I know that TEXT in blobspace bypasses buffers. So that would mean
> that every insert will result in more disk write. OTOH text in table may
> consume lot of buffers, even though it will avoid immediate disk write.
>
> TIA.

[Paul Watson]

Depending how you want to use it maybe look at creating your
opaque type

rkusenet wrote:

>
> IDS 9.21.
>
> We are in the process of making a change in a heavy insert table.
> This table gets lot of inserts. A row , after getting inserted,
> is read and updated for next few minutes by another process. After
> that the row has no utility left and is deleted at the end of the
> day.
>
> One of the columns in the table is a VARCHAR column. This column
> now will store additional information which can run upto 20K in
> length. This means both VARCHAR and LVARCHAR can not store that
> size of information. My main concern is the performance penalty
> during insert if the column is changed to a text field. Which is
> the best way to store this field. TEXT in TABLE or TEXT in
> blobspace. I know that TEXT in blobspace bypasses buffers. So that
> would mean that every insert will result in more disk write.
> OTOH text in table may consume lot of buffers, even though it
> will avoid immediate disk write.
>
> TIA.

--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
[url]www.oninit.com[/url] #

[Qweertz]

How can I create more then 1 text field while animation is playing?

I need to draw new point and write its name each time user clicks on button
"Draw point".
With point i don't have any problems but I don't know how to create text
fields with different names.

I tried using
_root.createTextField(something,...)
but I need to write some string instead of "something". Is there anyway to
put there element of array instead of "something"?

Can please someone help me?

Thanks