> On Thu, 16 Apr 2009 08:46:15 +0800, Craig Ringer said:
>
> Martin Simmons wrote:
> >> On Wed, 15 Apr 2009 11:58:08 +0800, Craig Ringer said:
> >> Anyway, the expanded schema:
>
> [snip]
>
> > Thanks, I was wondering what you had done about integers. Is integer a
> > 32-bit
> > quanti
Martin Simmons wrote:
>> On Wed, 15 Apr 2009 11:58:08 +0800, Craig Ringer said:
>> Anyway, the expanded schema:
[snip]
> Thanks, I was wondering what you had done about integers. Is integer a 32-bit
> quantity?
Yes.
> Beware that many of these stat fields are 64-bit on modern systems
> (ev
> On Wed, 15 Apr 2009 11:58:08 +0800, Craig Ringer said:
>
> Anyway, the expanded schema:
>
> CREATE TABLE file2 (
> fileid bigint,
> fileindex integer,
> jobid integer,
> pathid integer,
> filenameid integer,
> markid integer,
> st_dev integer,
> st_ino intege
Martin Simmons wrote:
> The schema you used for the native types would be useful to know too...
Oh, sorry, I thought I included it. Schema follows, but first:
I just tested COPY ... WITH BINARY in PostgreSQL as well.
Results:
Base64 ExpandedDiff %
Dump si
> On Sat, 11 Apr 2009 14:39:04 +0800, Craig Ringer said:
>
> The same schema definition was used for all tests; the only change was
> appending "ENGINE=MyISAM" or "ENGINE=InnoDB" for the MySQL tests. The
> schema was:
>
> CREATE TABLE file (
> fileid bigint NOT NULL,
> fileindex integ
Hi
I've been doing some testing to see what effects might be seen from
getting rid of the base64-encoded `lstat' field, instead storing the
values as native database fields.
As I already posted, there's no significant change in table size under
PostgreSQL. I needed to test this for the other bacu
