Thread: moving from MySQL to pgsql
Hi !
At present, I am using MySQL as backend for my work.
Because of the licensing implications, I am considering to shift from MySQL to pgsql.
Typically, my apps are multi-user, web based or LAN based.
1) Read over the internet that ---
Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be.
MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection.
source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS
In what way it might affect my app performance?
2) I run MySQL from a USB stick.
There is no installation required (on WinXP.). (not tried on Ubuntu)
Is it the same for pgsql?
3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else)
Thanks,
Vineet
At present, I am using MySQL as backend for my work.
Because of the licensing implications, I am considering to shift from MySQL to pgsql.
Typically, my apps are multi-user, web based or LAN based.
1) Read over the internet that ---
Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be.
MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection.
source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS
In what way it might affect my app performance?
2) I run MySQL from a USB stick.
There is no installation required (on WinXP.). (not tried on Ubuntu)
Is it the same for pgsql?
3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else)
Thanks,
Vineet
On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote:
Hi !
At present, I am using MySQL as backend for my work.
Because of the licensing implications, I am considering to shift from MySQL to pgsql.
Typically, my apps are multi-user, web based or LAN based.
1) Read over the internet that ---
Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be.
MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection.
source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS
In what way it might affect my app performance?
Not much. MySQL doesn't support intraquery parallelism to my knowledge. You will get extra robustness due to process isolation however. There might be some slight costs due to shared memory management overhead but these are probably insignificant compared to other factors. PostgreSQL has an excellent optimizer and the on-disk layout is completely different. This will dwarf any changes due to threads vs queries. However be prepared to rethink your indexing strategies.
2) I run MySQL from a USB stick.
There is no installation required (on WinXP.). (not tried on Ubuntu)
Is it the same for pgsql?
You would want a user account created because PostgreSQL won't run as an administrator but otherwise, yes.
3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else)
I would use smallint (2 byte int), but if you have to "char" with quotes should give you a one byte field. I don't know about utf8 tules on it though.
Best Wishes,
Chris Travers
body p { margin-bottom: 0cm; margin-top: 0pt; }
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" text="#000000"
bgcolor="#FFFFFF">
On 10/10/2012 10:47 AM, Vineet Deodhar
wrote:
<blockquote
cite="mid:CAP5=7opYu1y=uy=BxPeud-t9sRnMO_1-OJi_rKeG8cFU8SuivA@mail.gmail.com"
type="cite">Hi !
At present, I am using MySQL as backend for my work.
Because of the licensing implications, I am considering to shift
from MySQL to pgsql.
Typically, my apps are multi-user, web based or LAN based.
1) Read over the internet that ---
Postgres is not threaded, but every connection gets it's own
process. The OS will distribute the processes across the
processors. Basically a single connection will not be any faster
with SMP, but multiple connections will be.
MySQL is multi-threaded server so it can use many processors. A
separate thread is created for each connection.
source: <a moz-do-not-send="true"
href="http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS">http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS
In what way it might affect my app performance?
Performance will not be affected negatively. MySQL only has one
thread per connection, so a single query will never use multiple
threads (scary concept to think about).
<blockquote
cite="mid:CAP5=7opYu1y=uy=BxPeud-t9sRnMO_1-OJi_rKeG8cFU8SuivA@mail.gmail.com"
type="cite">2) I run MySQL from a USB stick.
There is no installation required (on WinXP.). (not tried on
Ubuntu)
Is it the same for pgsql?
To use postgres on a USB stick, see
<a
href="http://www.postgresonline.com/journal/archives/172-Starting-PostgreSQL-in-windows-without-install.html">http://www.postgresonline.com/journal/archives/172-Starting-PostgreSQL-in-windows-without-install.html
<blockquote
cite="mid:CAP5=7opYu1y=uy=BxPeud-t9sRnMO_1-OJi_rKeG8cFU8SuivA@mail.gmail.com"
type="cite">3) Can I simulate MySQL's TINYINT data-type (using
maybe the custom data type or something else)
You can either use bool or smallint with a constraint.
Sim
On Wed, Oct 10, 2012 at 2:38 PM, Chris Travers <chris.travers@gmail.com> wrote:
Thanks Chris.
I didn't understand by what do you mean by "be prepared to rethink your indexing strategies."
In MySQL, I have created indexes, Unique indexes, complex or multi-field indexes, etc.
In what way should I re-consider the indexing?
Thanks,
Vineet
On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: PostgreSQL has an excellent optimizer and the on-disk layout is completely different. This will dwarf any changes due to threads vs queries.
However be prepared to rethink your indexing strategies.Best Wishes,Chris Travers
Thanks Chris.
I didn't understand by what do you mean by "be prepared to rethink your indexing strategies."
In MySQL, I have created indexes, Unique indexes, complex or multi-field indexes, etc.
In what way should I re-consider the indexing?
Thanks,
Vineet
On Wed, Oct 10, 2012 at 2:20 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote:
On Wed, Oct 10, 2012 at 2:38 PM, Chris Travers <chris.travers@gmail.com> wrote:On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: PostgreSQL has an excellent optimizer and the on-disk layout is completely different. This will dwarf any changes due to threads vs queries.However be prepared to rethink your indexing strategies.Best Wishes,Chris Travers
Thanks Chris.
I didn't understand by what do you mean by "be prepared to rethink your indexing strategies."
In MySQL, I have created indexes, Unique indexes, complex or multi-field indexes, etc.
In what way should I re-consider the indexing?
In InnoDB your tables are basically primary key indexes with the rest of the row data attached. For this reason a sequential scan is *slow* since it cannot traverse the table in physical order. In PostgreSQL tables are indexed paged heaps and there is essentially no difference between a UNIQUE index on not null columns and a primary key.
What this means is that in MySQL/InnoDB more indexes are almost always better, because a sequential scan is always very slow. In PostgreSQL, sequential scans are pretty fast but primary key lookups are a little slower. Consequently on PostgreSQL you may want to reduce the number of non-unique indexes at first and add back as necessary.
On Wed, Oct 10, 2012 at 3:47 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > Hi ! > At present, I am using MySQL as backend for my work. > Because of the licensing implications, I am considering to shift from MySQL > to pgsql. > Typically, my apps are multi-user, web based or LAN based. > > 1) Read over the internet that --- > Postgres is not threaded, but every connection gets it's own process. The OS > will distribute the processes across the processors. Basically a single > connection will not be any faster with SMP, but multiple connections will > be. > > MySQL is multi-threaded server so it can use many processors. A separate > thread is created for each connection. > source: PostgreSQL is multi-threaded in that it has multiple execution threads. The only difference is that each thread has its own process where in mysql every thread runs in the same process. Each approach has various pros and cons that ultimately don't matter most applications. > In what way it might affect my app performance? Basically, it doesn't -- at least not very much. There are many other things that are going to make a much bigger difference. > 2) I run MySQL from a USB stick. > There is no installation required (on WinXP.). (not tried on Ubuntu) > Is it the same for pgsql? Not sure what you mean there. Mysql has a windows installer, as does postgres. It's possible to bootstrap postgres without an installer if you know what you're doing, but generally silent mode install is the way to go. You've omitted some very important details, like the specific security model of the windows environments you'll install to. > 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data > type or something else) You have a couple of options: Postgresql explicitly-double-quoted "char", which is a byte. Another options is to use smallint + check constraints. merlin
Hi, On 10 October 2012 19:47, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data > type or something else) What do you exactly mean? Do you care about storage requirements or constraints? The smallest numeric type in postgres is smallint: range is +/- 32K and you need two bytes. You can use check constraint to restrict the range (postgres doesn't have signed / unsigned types): create table T ( tint_signed smallint check ( tint_signed >= -128 and tint_signed =< 127 ), tint_unsigned smallint check ( tint_unsigned >= 0 and tint_unsigned =< 255 ) ) if you care about storage then "char" (yes, with quotes) might be the right type for you. -- Ondrej Ivanic (ondrej.ivanic@gmail.com) (http://www.linkedin.com/in/ondrejivanic)
I noticed something here that none of the other replies addressed. Vineet Deodhar wrote: > 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data > type or something else) The answer to your question depends on what you were using the TINYINT for. For example, many people use TINYINT in MySQL to store BOOLEAN (true/false) data because MySQL doesn't have a real BOOLEAN type; MySQL has the BOOLEAN keyword, but if you choose it then what you actually get is a TINYINT. And so, if you are actually using the field just for true/false or 1/0 values, then Postgres' BOOLEAN type (which is not a number) is the best thing for you to use. If you were storing actual numbers outside that range, then use SMALLINT or something like that. Any reverse engineering of the MySQL schema will never know you used the BOOLEAN keyword and just say you have a TINYINT, so you may have to study your schema and its uses more to know what kind of data/type you actually have. -- Darren Duncan
On 10/10/2012 02:18 AM, Sim Zacks wrote: >> 2) I run MySQL from a USB stick. >> There is no installation required (on WinXP.). (not tried on Ubuntu) >> Is it the same for pgsql? > To use postgres on a USB stick, see > http://www.postgresonline.com/journal/archives/172-Starting-PostgreSQL-in-windows-without-install.html > >> 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom >> data type or something else) > You can either use bool or smallint with a constraint. Or he could create a custom type easily enough. JD > > Sim -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579
On 10/10/2012 04:47 PM, Vineet Deodhar wrote: > 2) I run MySQL from a USB stick. > There is no installation required (on WinXP.). (not tried on Ubuntu) > Is it the same for pgsql? On Windows PostgreSQL is usually installed as a system service with its own user account (pre-9.2) or running in the network service account (9.2+). This isn't strictly required, though. You can keep the .zip binary releases on a USB key and use pg_ctl to start/stop them from your own scripts. If you're bundling Pg in your application this may be the best choice. See: http://www.enterprisedb.com/products-services-training/pgbindownload You *really* shouldn't keep the database its self on a USB key. Performance is likely to be terrible, and many USB keys have quite short write lifetimes so a database on a USB key can wear some of them out in a real hurry. Think about your backup process too. With PostgreSQL you have a couple of options, including log archiving, periodic dumps, and warm standby. Please read the backup chapter of the manual in detail. -- Craig Ringer
On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič <ondrej.ivanic@gmail.com> wrote:
Yes. Considering the storage requirements , I am looking for TINYINT kind of data type.
If I use "char" for numeric field, would it be possible to do numeric operations comparisons such as max(tint_unsigned) ?
--- Vineet
Hi,What do you exactly mean? Do you care about storage requirements or
On 10 October 2012 19:47, Vineet Deodhar <vineet.deodhar@gmail.com> wrote:
> 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data
> type or something else)
constraints? The smallest numeric type in postgres is smallint: range
is +/- 32K and you need two bytes. You can use check constraint to
restrict the range (postgres doesn't have signed / unsigned types):
create table T (
tint_signed smallint check ( tint_signed >= -128 and tint_signed =< 127 ),
tint_unsigned smallint check ( tint_unsigned >= 0 and tint_unsigned =< 255 )
)
Yes. Considering the storage requirements , I am looking for TINYINT kind of data type.
if you care about storage then "char" (yes, with quotes) might be the
right type for you.--
Ondrej Ivanic
(ondrej.ivanic@gmail.com)
(http://www.linkedin.com/in/ondrejivanic)
If I use "char" for numeric field, would it be possible to do numeric operations comparisons such as max(tint_unsigned) ?
--- Vineet
Le 10/10/2012 10:47, Vineet Deodhar a écrit :
> Hi !
>
> 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data
> type or something else)
>
Another way, and a good practice toot is to use SQL DOMAINs wich is a
part of the ISO SQL since 1992 that MySQL don't have...
CREATE DOMAIN TINYINT
AS SMALLINT
CHECK (VALUE BETWEEN 0 AND 255)
Most part of the modelling tools are able to use DOMAINs in their
modelling process, like PowerDesigner, Mega, ERwin, Rational...
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
On 10/11/2012 02:07 PM, Vineet Deodhar wrote:
> On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič <ondrej.ivanic@gmail.com
> <mailto:ondrej.ivanic@gmail.com>> wrote:
>
> Hi,
>
> On 10 October 2012 19:47, Vineet Deodhar <vineet.deodhar@gmail.com
> <mailto:vineet.deodhar@gmail.com>> wrote:
> > 3) Can I simulate MySQL's TINYINT data-type (using maybe the
> custom data
> > type or something else)
>
> What do you exactly mean? Do you care about storage requirements or
> constraints? The smallest numeric type in postgres is smallint: range
> is +/- 32K and you need two bytes. You can use check constraint to
> restrict the range (postgres doesn't have signed / unsigned types):
>
> create table T (
> tint_signed smallint check ( tint_signed >= -128 and tint_signed
> =< 127 ),
> tint_unsigned smallint check ( tint_unsigned >= 0 and
> tint_unsigned =< 255 )
> )
>
>
> Yes. Considering the storage requirements , I am looking for TINYINT
> kind of data type.
The storage difference between `SMALLINT` and a `TINYINT` would be ...
tiny, given the space taken up by tuple headers, etc.
As it is, a row containing four SMALLINT columns is 32 bytes, vs 40
bytes for INTEGER columns or 28 for BOOLEAN.
regress=# SELECT pg_column_size( (BOOLEAN 't', BOOLEAN 't', BOOLEAN 'f',
BOOLEAN 'f') );
pg_column_size
----------------
28
(1 row)
regress=# SELECT pg_column_size( (SMALLINT '2', SMALLINT '3', SMALLINT
'4', SMALLINT '5') );
pg_column_size
----------------
32
(1 row)
regress=# SELECT pg_column_size( (INTEGER '2', INTEGER '3', INTEGER '4',
INTEGER '5') );
pg_column_size
----------------
40
(1 row)
The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported
it) is 1 byte per column. If you had 30 smallint columns and quite a few
million rows it might start making a difference, but it's *really* not
worth obsessing about. Unless you have high-column-count tables that
contain nothing but lots of integers of range 0-255 there's no point caring.
--
Craig Ringer
On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer <ringerc@ringerc.id.au> wrote:
The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported it) is 1 byte per column. If you had 30 smallint columns and quite a few million rows it might start making a difference, but it's *really* not worth obsessing about. Unless you have high-column-count tables that contain nothing but lots of integers of range 0-255 there's no point caring.
--
Craig Ringer
To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient.
These pkid's are used as fk constraints in tables for storing business transactions.
The no. of rows in business transactions tables is in millions.
Here, I NEED to worry about the storage space occupied by the pkid fields.
-- Vineet
On 10/11/2012 05:07 PM, Vineet Deodhar wrote: > On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer <ringerc@ringerc.id.au > <mailto:ringerc@ringerc.id.au>> wrote: > > The difference between SMALLINT and BOOLEAN (or TINYINT if Pg > supported it) is 1 byte per column. If you had 30 smallint columns > and quite a few million rows it might start making a difference, but > it's *really* not worth obsessing about. Unless you have > high-column-count tables that contain nothing but lots of integers > of range 0-255 there's no point caring. > > -- > Craig Ringer > > > To give an example, I have tables for storing master records (year > master, security master, etc.) for which pkid TINYINT is just sufficient. > These pkid's are used as fk constraints in tables for storing business > transactions. > The no. of rows in business transactions tables is in millions. > Here, I NEED to worry about the storage space occupied by the pkid fields. AFAIK in most situations alignment requirements will mean you won't gain any space in those situations anyway. I would be truly amazed if you saw more than something like a 1% difference in size due to this; it'll be *massively* outweighed by all the other differences. You're optimising prematurely. See if it's a problem in practice, and if it is look into using a custom data type (warning: lots of work) or some other approach. -- Craig Ringer
On Thu, Oct 11, 2012 at 3:04 PM, Craig Ringer <ringerc@ringerc.id.au> wrote:
AFAIK in most situations alignment requirements will mean you won't gain any space in those situations anyway.
I would be truly amazed if you saw more than something like a 1% difference in size due to this; it'll be *massively* outweighed by all the other differences. You're optimising prematurely. See if it's a problem in practice, and if it is look into using a custom data type (warning: lots of work) or some other approach.
--
Craig Ringer
OK.
As per your advise, let me put smallint into practice and analyze the storage requirement.
Thanks a lot.
-- Vineet
--
Best regards,
Vineet Deodhar
0 9270012422 ( Sales)
0 9420 6767 41 / 0 844 6268 488 (Service)
0233-2300136 (Back-Office)
Thanks all for your replies.
This is my first experience with postgres mailing list.
Hats Off to the active community of pgsql.
This has definitely raised my confidence level with postgres.
--- Vineet
This is my first experience with postgres mailing list.
Hats Off to the active community of pgsql.
This has definitely raised my confidence level with postgres.
--- Vineet
On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > Thanks all for your replies. > This is my first experience with postgres mailing list. > Hats Off to the active community of pgsql. > This has definitely raised my confidence level with postgres. thanks. we like emails that start off 'moving to pgsql from xxx'. If you want a 24x7 crack dedicated support team, claim to be frustrated with postgres and evaluating migration to SQL Server. :-). merlin
On 12/10/12 04:39, Merlin Moncure wrote: > On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar > <vineet.deodhar@gmail.com> wrote: >> Thanks all for your replies. >> This is my first experience with postgres mailing list. >> Hats Off to the active community of pgsql. >> This has definitely raised my confidence level with postgres. > thanks. we like emails that start off 'moving to pgsql from xxx'. > > If you want a 24x7 crack dedicated support team, claim to be > frustrated with postgres and evaluating migration to SQL Server. :-). > > merlin > > Surely we should le people migrate to SQL Server grom postgres - as it will be its own punishment? :-) Cheers, Gavin
On Thu, Oct 11, 2012 at 9:38 AM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
On 12/10/12 04:39, Merlin Moncure wrote:Surely we should le people migrate to SQL Server grom postgres - as it will be its own punishment? :-)On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar
<vineet.deodhar@gmail.com> wrote:Thanks all for your replies.thanks. we like emails that start off 'moving to pgsql from xxx'.
This is my first experience with postgres mailing list.
Hats Off to the active community of pgsql.
This has definitely raised my confidence level with postgres.
If you want a 24x7 crack dedicated support team, claim to be
frustrated with postgres and evaluating migration to SQL Server. :-).
merlin
I'll take SQL Server over Oracle any day of the week though..
On 10/11/12 2:07 AM, Vineet Deodhar wrote: > To give an example, I have tables for storing master records (year > master, security master, etc.) for which pkid TINYINT is just sufficient. > These pkid's are used as fk constraints in tables for storing business > transactions. > The no. of rows in business transactions tables is in millions. > Here, I NEED to worry about the storage space occupied by the pkid fields. IMHO, its not significant to save a byte per field unless there's 30 or 100 of these fields in a single row. -- john r pierce N 37, W 122 santa cruz ca mid-left coast
On 2012-10-10, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > --f46d040714c5d7a08c04cbb08256 > Content-Type: text/plain; charset=UTF-8 > > Hi ! > At present, I am using MySQL as backend for my work. > Because of the licensing implications, I am considering to shift from MySQL > to pgsql. > Typically, my apps are multi-user, web based or LAN based. > > 1) Read over the internet that --- > Postgres is not threaded, but every connection gets it's own process. The > OS will distribute the processes across the processors. Basically a single > connection will not be any faster with SMP, but multiple connections will > be. > > MySQL is multi-threaded server so it can use many processors. A separate > thread is created for each connection. > source: > http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS > > In what way it might affect my app performance? It's going to hurt a bit if creating processes is expensive and you need many. > 2) I run MySQL from a USB stick. > There is no installation required (on WinXP.). (not tried on Ubuntu) > Is it the same for pgsql? It's probably possible, but usb flash gets you all the disadvantages of SSD with no benefits (except portability), you'd probably have to reformat the usb to NTFS - windows FAT doesn't support postgres. And you'd also need to do a custom install. > 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data > type or something else) Probably what properties of tinyint do you need? -- ⚂⚃ 100% natural
On 2012-10-11, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > To give an example, I have tables for storing master records (year master, > security master, etc.) for which pkid TINYINT is just sufficient. > These pkid's are used as fk constraints in tables for storing business > transactions. > The no. of rows in business transactions tables is in millions. > Here, I NEED to worry about the storage space occupied by the pkid fields. with disk at about 50c/Gigabyte why is it you need to worry? -- ⚂⚃ 100% natural
On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts <jasen@xnet.co.nz> wrote: > On 2012-10-11, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: > >> To give an example, I have tables for storing master records (year master, >> security master, etc.) for which pkid TINYINT is just sufficient. >> These pkid's are used as fk constraints in tables for storing business >> transactions. >> The no. of rows in business transactions tables is in millions. >> Here, I NEED to worry about the storage space occupied by the pkid fields. > > with disk at about 50c/Gigabyte why is it you need to worry? see upthread: OP is running off a USB stick. If he's running MyISAM, the postgres database is going to be larger and there is going to be a lot more writing than he's used to. merlin
On 2012-10-13, Merlin Moncure <mmoncure@gmail.com> wrote: > On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts <jasen@xnet.co.nz> wrote: >> On 2012-10-11, Vineet Deodhar <vineet.deodhar@gmail.com> wrote: >> >>> To give an example, I have tables for storing master records (year master, >>> security master, etc.) for which pkid TINYINT is just sufficient. >>> These pkid's are used as fk constraints in tables for storing business >>> transactions. >>> The no. of rows in business transactions tables is in millions. >>> Here, I NEED to worry about the storage space occupied by the pkid fields. >> >> with disk at about 50c/Gigabyte why is it you need to worry? > > see upthread: OP is running off a USB stick. If he's running MyISAM, > the postgres database is going to be larger and there is going to be a > lot more writing than he's used to. > So, $5/gigabyte, and shorter life than disk, I can see how that could start to hurt if you need to deploy a thousand. -- ⚂⚃ 100% natural