On Fri, Jul 04, 2003 at 02:22:39PM -0700, Maksim Likharev wrote:
> Ok, what I see here tells me that text is slower then fixed len varchar,
> due to stored in separate table ( but how else you can store long fields
> ).
No, sorry, I think I was unclear. varchar() is the same thing as
text(); they
Just because all reported commits go in doesn't mean there won't be any
data loss.
If you pull the power cord, the DB should be in a consistent state barring
hardware and other issues. However there can be data loss, because the
clients might have been inserting data which may not be able to be
On Monday 07 Jul 2003 4:11 pm, Mattias Kregert wrote:
> > > If I turn fsync on and then pull the power cord while a
> > > number of clients are doing lots of inserts/updates and stuff,
> > > will the fsync then guarantee that no data will be lost or
> > > corrupted?
> >
> > You are surely kidding,
, 2003 3:59 AM
To: Alvaro Herrera; Maksim Likharev
Cc: PostgreSQL List
Subject: Re: [GENERAL] Datatypes and performance
First of all, disable FSYNC... that will speed things up a lot!
/M
- Original Message -
From: "Alvaro Herrera" <[EMAIL PROTECTED]>
To: "Maksim Likhar
> > If I turn fsync on and then pull the power cord while a
> > number of clients are doing lots of inserts/updates and stuff,
> > will the fsync then guarantee that no data will be lost or
> > corrupted?
> You are surely kidding, aren't you ?
>
> Karsten
No. No kidding.
Just to clarify, what I m
> If I turn fsync on and then pull the power cord while a
> number of clients are doing lots of inserts/updates and stuff,
> will the fsync then guarantee that no data will be lost or
> corrupted?
You are surely kidding, aren't you ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291
Tom Lane wrote:
> "Mattias Kregert" <[EMAIL PROTECTED]> writes:
> > [ misguided analysis ]
>
> > Journalling FS will fix the FS problems, so the files are ok.
> > PG journal will fix the PG problems so the tables will be ok.
>
> Only if the journal is all down to disk before the crash.
>
> The f
"Mattias Kregert" <[EMAIL PROTECTED]> writes:
> [ misguided analysis ]
> Journalling FS will fix the FS problems, so the files are ok.
> PG journal will fix the PG problems so the tables will be ok.
Only if the journal is all down to disk before the crash.
The fundamental problem with fsync off
On Mon, Jul 07, 2003 at 01:30:09PM +0200, Mattias Kregert wrote:
> In the case of disk failure, the files will probably be damaged anyway and
> then i'll have to install new hardware or format+check badblocks and then
> restore from the backup. I can't see how fsync would help in the case of
> dis
In the case of disk failure, the files will probably be damaged anyway and then i'll
have to install new hardware or format+check badblocks and then restore from the
backup. I can't see how fsync would help in the case of disk crash. Without reliable
raid or something i think this would be a cat
On 7 Jul 2003 at 12:59, Mattias Kregert wrote:
> First of all, disable FSYNC... that will speed things up a lot!
That shouldn't have been done so casually. Though can cause performance boost
and it degrades reliability of data as it can cause data corruption in case of
power/disk failure.
Bye
char under 4K
if you want to read it fast.
Pretty useful detail, thank you.
-Original Message-
From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
Sent: Friday, July 04, 2003 2:54 PM
To: Maksim Likharev
Cc: PostgreSQL List
Subject: Re: [GENERAL] Datatypes and performance
On Fri, Jul 04, 200
On Fri, Jul 04, 2003 at 02:22:39PM -0700, Maksim Likharev wrote:
> Ok, what I see here tells me that text is slower then fixed len varchar,
> due to stored in separate table ( but how else you can store long fields
> ).
> so postgres has to read another page(s) in order to get long value.
That's r
ullivan [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 04, 2003 1:24 PM
> To: PostgreSQL List
> Subject: Re: [GENERAL] Datatypes and performance
>
>
> On Fri, Jul 04, 2003 at 01:14:52PM -0700, Maksim Likharev wrote:
> > How postgres internally stores text fields, in a separ
comparing with disk reads/writes.
-Original Message-
From: Andrew Sullivan [mailto:[EMAIL PROTECTED]
Sent: Friday, July 04, 2003 1:24 PM
To: PostgreSQL List
Subject: Re: [GENERAL] Datatypes and performance
On Fri, Jul 04, 2003 at 01:14:52PM -0700, Maksim Likharev wrote:
> How postg
On Fri, Jul 04, 2003 at 01:14:52PM -0700, Maksim Likharev wrote:
> How postgres internally stores text fields, in a separate table?
I believe it gets stored in a separate table just in case it's too
long (read the docs on TOAST if you want more about this). But
normally, no. Here's what the docs
How postgres internally stores text fields, in a separate table?
-Original Message-
From: Andrew Sullivan [mailto:[EMAIL PROTECTED]
Sent: Friday, July 04, 2003 12:55 PM
To: PostgreSQL List
Subject: Re: [GENERAL] Datatypes and performance
On Fri, Jul 04, 2003 at 09:10:41AM -0700, Jay
On Fri, Jul 04, 2003 at 09:10:41AM -0700, Jay O'Connor wrote:
> Based on the docs, they say that there's not performance difference between
> using varchar(n) and text.
>
> So will leaving my fields as unlimited varchar be a performance issue? Or
> should I try to narrow them down?
In fact, ther
On Fri, Jul 04, 2003 at 09:10:41AM -0700, Jay O'Connor wrote:
> I created a database schema and based on the test data I had to work with,
> I couldn't really determine the max size of a lot of string fields so I
> just left a lot of fields as varchar
>
> A comment from a coworker was that this w
On Friday 04 July 2003 21:40, Jay O'Connor wrote:
> 2.varchar and int
> I was using a varchar as one field that's part of an index. Looking at the
> data, I realized I could just use an int instead. My assumption would be
> that an int would be faster to serach for thena varchar, so I converted
Couple of questions on datat types and performance
1. varchar vs varchar(2)
I created a database schema and based on the test data I had to work with,
I couldn't really determine the max size of a lot of string fields so I
just left a lot of fields as varchar
A comment from a coworker was that t
21 matches
Mail list logo
