Обсуждение: Text column with large amounts of data

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

Text column with large amounts of data

От
Kieran McCusker
Дата:
Hi

I know there is already a known issue in the GRD for columns with a 
large amount of data but is it known that the same problem appears in 
the query window?

I am using postgresql to capture email content (in a text field) and it 
is impossible to use pgadmin to browse the table in either the grid or 
query window. I'm using pgadmin 1.8.1 and postgresql 8.2.5.

I was wondering if it would not be possible to only put something like 
the first line/first 1kb/etc of characters into the grid? (The rest 
could be loaded if the user clicks into the field)

Anyway I'm just thinking aloud, thanks for a great piece of software.

Kieran


Re: Text column with large amounts of data

От
"Dave Page"
Дата:
On 04/01/2008, Kieran McCusker <kieran.mccusker@kwest.info> wrote:
> Hi
>
> I know there is already a known issue in the GRD for columns with a
> large amount of data but is it known that the same problem appears in
> the query window?

Yes, it will.

> I am using postgresql to capture email content (in a text field) and it
> is impossible to use pgadmin to browse the table in either the grid or
> query window. I'm using pgadmin 1.8.1 and postgresql 8.2.5.

How big are the emails? Normally when people run into issues in either
tool it's will individual values running into multiple-megabytes
(multiplied by however many rows are loaded).

> I was wondering if it would not be possible to only put something like
> the first line/first 1kb/etc of characters into the grid? (The rest
> could be loaded if the user clicks into the field)

See the 'Max characters per column' option on the Query tab of the
Options dialogue (http://www.pgadmin.org/docs/1.8/options-tab3.html).
This will only affect the query tool, not the edit grid (where the
whole point is that the actual data be edited, not a summary).

Regards, Dave


Re: Text column with large amounts of data

От
"Dave Page"
Дата:
On 04/01/2008, Dave Page <dpage@postgresql.org> wrote:
> On 04/01/2008, Kieran McCusker <kieran.mccusker@kwest.info> wrote:
> > Dave
> >
> > Does Max characters per column work in 1.8.1?  Whatever I set the limit does
> > not seem to affect text fields?
>
> It should do, but maybe it got broken :-(. I'll add it to my todo list.

Yes, it did get broken quite a while back. The attached patch will fix
it again, but this is potentially problematic because

a) it's a non-obvious change in behaviour over last last few releases

b) the default setting means it will be turned on (because the default
value is 256, not zero).

c) we don't know if any data is actually truncated until the cell is
rendered, meaning we cannot popup a warning at query completion time.

The safest option seems to me to be to apply the patch to trunk, and
change the default to zero, using a different config option to ensure
we don't pickup the old default form prior installations.

Thoughts anyone?

/D

Вложения

Re: Text column with large amounts of data

От
"Belbin, Peter"
Дата:

Sounds good to me.  This has been a bug-bear for me for a long time too.

-----Original Message-----
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dave Page
Sent: Monday, January 07, 2008 10:11 AM
To: Kieran McCusker
Cc: pgadmin-support@postgresql.org; pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-support] Text column with large amounts of data

On 04/01/2008, Dave Page <dpage@postgresql.org> wrote:
> On 04/01/2008, Kieran McCusker <kieran.mccusker@kwest.info> wrote:
> > Dave
> >
> > Does Max characters per column work in 1.8.1?  Whatever I set the limit does
> > not seem to affect text fields?
>
> It should do, but maybe it got broken :-(. I'll add it to my todo list.

Yes, it did get broken quite a while back. The attached patch will fix
it again, but this is potentially problematic because

a) it's a non-obvious change in behaviour over last last few releases

b) the default setting means it will be turned on (because the default
value is 256, not zero).

c) we don't know if any data is actually truncated until the cell is
rendered, meaning we cannot popup a warning at query completion time.

The safest option seems to me to be to apply the patch to trunk, and
change the default to zero, using a different config option to ensure
we don't pickup the old default form prior installations.

Thoughts anyone?

/D

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named.  Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.