Re: Effective limit on size of text type?

On Wed, 07 Aug 2002 22:30:02 -0400 in message <28712(dot)1028773802(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> eric soroos <eric-psql(at)soroos(dot)net> writes:
> > test=# select _incomingEnclosures from dl_event where _idNum=3010;
> > Takes at least a couple of minutes, either through psql or a libpq based connection.
> > test=# select char_length(_incomingEnclosures) from dl_event where _donorNum=804 and _responseNum=3010;
> > -[ RECORD 1 ]-------
> > char_length | 952478
> > Is nearly immediate.
>
> Given that those queries aren't using comparable WHERE conditions, I'd
> wonder about the query plan myself, not the size of the returned data
> item. Do you have an index on _idNum? Is it getting used?

Sorry, that is my fault. I was trying to simplify the conditions. And in doing so, I created a red herring. Both queries were on _donorNum/_responseNum, which together form a unique indexed key.

test-# explain select _incomingEnclosures from dl_event where _donorNum='6' and _responseNum='3549';
NOTICE: QUERY PLAN:

Index Scan using dl_event_rnumidx on dl_event (cost=0.00..6.46 rows=1 width=536)

> In a quick test here, selecting a 1MB text value into a file, using
>
> regression=# select f1 from foo
> regression-# \g tmpfile
>
> took about a tenth of a second...

Ok, tried that and it was about that fast with extended view off. With extended view on, it churns for a while before I give up.

So it appears that this is an artifact of the front end, since the same query with different front end settings has drastically different performance.

And under a little further investigation, it appears that is a similar 'run at the proper speed' flag somewhere in the library I'm using since testing this morning is running at a reasonable (~1sec) speed.

eric