Sorry yes, I meant Char().
Bob S
> On Mar 2, 2015, at 20:00 , Dr. Hawkins wrote:
>
> On Mon, Mar 2, 2015 at 9:25 AM, Bob Sneidar
> wrote:
>
>> To optimize connections and transfer of data, one of the things you can do
>> is use VarChar() instead of TEXT whenever possible. A very knowledgabl
On Mon, Mar 2, 2015 at 8:21 PM, Richard Gaskin
wrote:
> Local DB performance like that makes a good case for working with text
> files. :)
>
> How many records are in there? Complex indices? What could account for
> so much time to connect locally?
>
It *is* entirely text.
"remote" postgres
Dr. Hawkins wrote:
> As a rough, from a fast link at home (10Mbs?), it takes "several"
> seconds for the series of transactions it takes me to open a client
> table, compared to "a second or two" on my desktop (which hosts the
> server) on a good business link.
Local DB performance like that mak
On Sun, Mar 1, 2015 at 9:27 AM, Richard Gaskin
wrote:
> Dr. Hawkins and others have noted that the time required for LC to connect
> to a database can be long enough to add up under load.
>
> To get a good feel for the implications of this, and to explore options
> for possibly mitigating it, it
On Mon, Mar 2, 2015 at 9:25 AM, Bob Sneidar
wrote:
> To optimize connections and transfer of data, one of the things you can do
> is use VarChar() instead of TEXT whenever possible. A very knowledgable web
> designer explained to me that TEXT types pad the storage values to fill the
> defined sto
To optimize connections and transfer of data, one of the things you can do is
use VarChar() instead of TEXT whenever possible. A very knowledgable web
designer explained to me that TEXT types pad the storage values to fill the
defined storage size for that column, whereas VarChar only stores as
