My questions briefly:
(1) I made experiments with large (millions of rows/elements) arrays
of text (text[], each element is 20-30 characters). On 7.4 (Debian
Sarge prepackaged), inserting such an array takes forever (10
thousand elements per minute), but accessing, or writing an
el
Antonios Christofides <[EMAIL PROTECTED]> writes:
> Why 25 seconds for appending an element?
Would you give us a specific test case, rather than a vague description
of what you're doing?
> (2) I also tried using a large (80M) text instead (i.e. instead of
> storing an array of lines, I st
On Tuesday 15 Feb 2005 8:03 pm, Antonios Christofides wrote:
> I'm also considering a table, of course, where each timeseries record
> will be one row. I have experimented only a little with that (id
> integer, date timestamp, value double precision, flags text, primary
> key(id, date)). It appears
Tom Lane wrote:
> Antonios Christofides <[EMAIL PROTECTED]> writes:
> > Why 25 seconds for appending an element?
>
> Would you give us a specific test case, rather than a vague description
> of what you're doing?
OK, sorry, here it is (on another machine, thus times are different.
8.0.1 on a
Shridhar Daithankar wrote:
> Perhaps you could attempt to store a fix small number of records per row, say
> 4-6? Or may be a smaller fixed size array, That should make the row overhead
> less intrusive...
Thanks, I didn't like your idea, but it helped me come up with another
idea:
(timeser
Antonios Christofides <[EMAIL PROTECTED]> writes:
> CREATE TABLE test(id integer not null primary key, records text[]);
> UPDATE test SET records[207] = 'hello, world!';
> [11 seconds]
> UPDATE test SET records[100] = 'hello, world!';
> [15 seconds (but the difference may be because of sys
