Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-13, Merlin Moncure mmonc...@gmail.com wrote: On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts ja...@xnet.co.nz wrote: On 2012-10-11, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-10, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-11, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts ja...@xnet.co.nz wrote: On 2012-10-11, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič ondrej.iva...@gmail.comwrote: Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@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. if you care about storage then char (yes, with quotes) might be the right type for you. -- Ondrej Ivanic (ondrej.iva...@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
Re: [GENERAL] moving from MySQL to pgsql
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 * -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 10/11/2012 02:07 PM, Vineet Deodhar wrote: On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič ondrej.iva...@gmail.com mailto:ondrej.iva...@gmail.com wrote: Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@gmail.com mailto:vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer ring...@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
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 3:04 PM, Craig Ringer ring...@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)
Re: [GENERAL] moving from MySQL to pgsql
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
Re: [GENERAL] moving from MySQL to pgsql
On 10/11/2012 05:07 PM, Vineet Deodhar wrote: On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer ring...@ringerc.id.au mailto:ring...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 12/10/12 04:39, Merlin Moncure wrote: On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 9:38 AM, Gavin Flower gavinflo...@archidevsys.co.nz wrote: On 12/10/12 04:39, Merlin Moncure wrote: On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@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? :-) I'll take SQL Server over Oracle any day of the week though..
Re: [GENERAL] moving from MySQL to pgsql
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 pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar vineet.deod...@gmail.comwrote: 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
Re: [GENERAL] moving from MySQL to pgsql
On 10/10/2012 10:47 AM, Vineet Deodhar 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? 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). 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. Sim
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 2:38 PM, Chris Travers chris.trav...@gmail.comwrote: On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar vineet.deod...@gmail.comwrote: 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
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 3:47 AM, Vineet Deodhar vineet.deod...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@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.iva...@gmail.com) (http://www.linkedin.com/in/ondrejivanic) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Michael Chaney wrote: On Thu, Mar 04, 2004 at 10:50:50AM -0500, Tom Lane wrote: If I understood the requirements correctly, it might be sufficient to put a unique index on (id1,id2). If two transactions simultaneously try to insert for the same id1, one would get a duplicate-index-entry failure, and it would have to retry. The advantage is you take no table-wide lock. So if the normal usage pattern involves lots of concurrent inserts for different id1 values, you'd come out ahead. Whether that applies, or is worth the hassle of a retry loop in the application, I can't tell from the info we've been given. Not a bad idea, but probably best to move it into a stored procedure in that case. But there isn't any exception handling - the duplicate-index-entry failure will abort the procedure and return to the client with an error. The only place to loop would be in the client AFAICS. Mike Mascari ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Thu, Mar 04, 2004 at 10:50:50AM -0500, Tom Lane wrote: If I understood the requirements correctly, it might be sufficient to put a unique index on (id1,id2). If two transactions simultaneously try to insert for the same id1, one would get a duplicate-index-entry failure, and it would have to retry. The advantage is you take no table-wide lock. So if the normal usage pattern involves lots of concurrent inserts for different id1 values, you'd come out ahead. Whether that applies, or is worth the hassle of a retry loop in the application, I can't tell from the info we've been given. Not a bad idea, but probably best to move it into a stored procedure in that case. Michael -- Michael Darrin Chaney [EMAIL PROTECTED] http://www.michaelchaney.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Harald Fuchs wrote: In article [EMAIL PROTECTED], "scott.marlowe" [EMAIL PROTECTED] writes: On Tue, 2 Mar 2004, [UTF-8] Paulovi Michal wrote: how you solve the problem with multilevel autoicrement? In MySQL you create table with col1, col2. Col 2 is AUTOICREMENT and you have to create UNIQUE INDEX (Col1, Col2). If you insert to this table for col1 volume 1, col2 automaticaly increase by one. Example: Insert into table values (1); Insert into table values (1); Insert into table values (2); Insert into table values (1); Insert into table values (2); I did this in MySQL and got this: create table test (id1 int, id2 int auto_increment, primary key(id2)); Query OK, 0 rows affected (0.00 sec) mysql alter table test add unique index (id1, id2); Query OK, 0 rows affected (0.09 sec) Records: 0 Duplicates: 0 Warnings: 0 You can't have a multi-level autoincrement if you make the second level unique. Use the following instead: create table test (id1 int, id2 int auto_increment, primary key(id1,id2)); Note that this trick works only for the MyISAM and BDB table types, not for InnoDB. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :-
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, Mar 03, 2004 at 18:12:18 +0100, Paulovi?? Michal [EMAIL PROTECTED] wrote: You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :- That isn't an appropiate use of sequences. You should only be using their uniqeness. If the values are supposed to have some other semantics you should be using another mechanism. Also Posgtesql 7.1 is very old. You really should upgrade to something more recent. 7.4.2 is due out in a few days. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, 3 Mar 2004, [UTF-8] Paulovič Michal wrote: Yes I know, But how you do this at PgSQL OK, I just read the response where someone showed me how to make such a table in mysql. What an odd, and non-intuitive behaviour that is. Anyway, first off, upgrade your version of postgresql to 7.4.x . 7.1 is VERY old, and is no longer maintained. IT would suck to develop all this for 7.1 only to find out some minor bug fix gets in your way of upgrading. Next, what you need is a before trigger that will take any row being inserted, select the max(id2) where id1 = whatwereinserting adds one to it and makes that the new id2. Look up before triggers. plpgsql is a good language to do this in. Note that on large tables it WILL BE SLOW. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Bruno Wolff III wrote: On Wed, Mar 03, 2004 at 18:12:18 +0100, Paulovi?? Michal [EMAIL PROTECTED] wrote: You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :- That isn't an appropiate use of sequences. You should only be using their uniqeness. If the values are supposed to have some other semantics you should be using another mechanism. Also Posgtesql 7.1 is very old. You really should upgrade to something more recent. 7.4.2 is due out in a few days. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com Yes, :( I have thought about this issue. Upgrade of PgSQL might by first step - probably. In other node at this formu other colegue give me an idea but it works on 7.2 and newer. Yes I have to try negotiate with provider of my DB enviroment for upgrading version of PgSQL. tnx a lot for all ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, Mar 03, 2004 at 06:45:56AM +0100, Paulovi?? Michal wrote: Yes I know, But how you do this at PgSQL You have to lock the table exclusively, get the max value for your particular id1, increment it, insert the row, and commit: begin; lock table test in exclusive mode; insert into test values (1,(select max(id2) from test where id1=1)+1); commit; It's not pretty, and it'll probably slow down as the table grows. MySQL probably suffers the same problem. Michael -- Michael Darrin Chaney [EMAIL PROTECTED] http://www.michaelchaney.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Michael Chaney [EMAIL PROTECTED] writes: begin; lock table test in exclusive mode; insert into test values (1,(select max(id2) from test where id1=1)+1); commit; It's not pretty, and it'll probably slow down as the table grows. As-is, that will definitely get pretty slow on large tables. You could avoid the slowdown with the standard hack for replacing max() with an index probe: insert into test values (1, (select id2+1 from test where id1=1 order by id1 desc, id2 desc limit 1) ); This will be fast if there is a double-column index on (id1, id2). regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Database metadata queries (WAS Re: [GENERAL] Moving from MySQL to PGSQL....some questions)
On Mon, Mar 01, 2004 at 11:09:32 -0600, Shawn Harrison [EMAIL PROTECTED] wrote: Would it be worthwhile to move many of these \d queries into the system schema, as views on various system tables? I've thought that it would be very useful to be able to access these things through the web or other clients. I could see the benefit of providing users with a consistent interface to such database metadata, no matter what client one is using. (OTOH, one could argue, learning to do that is a pgsql rite-of-passage. ;- ). If you are using 7.4.x look at the information_schema schema. This is going to provide a stable way to get meta data. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
Michael Chaney wrote: One other note, for those converting a database from MySQL to PostgreSQL, I have a table creation conversion script here: http://www.michaelchaney.com/downloads/m2p.pl I know that two come with PostgreSQL in the contrib directory, but I wrote this because those two didn't do what I needed. With this, you should be able to take the MySQL table creation scripts (as created by mysqldump --tab=x) and directly build the tables and load the data into a PostgreSQL db with little effort. Please share what yours does that the /contrib doesn't, and ideally, send in a patch or let us add your version to /contrib. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
how you solve the problem with multilevel autoicrement? In MySQL you create table with col1, col2. Col 2 is AUTOICREMENT and you have to create UNIQUE INDEX (Col1, Col2). If you insert to this table for col1 volume 1, col2 automaticaly increase by one. Example: Insert into table values (1); Insert into table values (1); Insert into table values (2); Insert into table values (1); Insert into table values (2); Result is: 1,1 1,2 2,1 1,3 2,2 How you convert this functionality from MySQL to PgSQL??? -- Bruce Momjian wrote: Michael Chaney wrote: One other note, for those converting a database from MySQL to PostgreSQL, I have a table creation conversion script here: http://www.michaelchaney.com/downloads/m2p.pl I know that two come with PostgreSQL in the contrib directory, but I wrote this because those two didn't do what I needed. With this, you should be able to take the MySQL table creation scripts (as created by mysqldump --tab=x) and directly build the tables and load the data into a PostgreSQL db with little effort. Please share what yours does that the /contrib doesn't, and ideally, send in a patch or let us add your version to /contrib. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
In PGAdmin III -- you might want to UNCHECK the Display system objects option under the Display menu option -- this will prevent you from seeing all of the non-public schema's and limit your view in PGAdmin to just the databases you created... Most people dont really need to dink around with the system tables anyway... As you probably noticed -- postgreSQL is a different beast than MS Access and mySQL -- postgreSQL is a true RDBMS like Sybase, Orale, and SQL Server... postgrSQL is a true 'client/server' RDBMS -- it does not contain it's own GUI client like MS Access postgreSQL is NOT just a high-powered version of MS Access or mySQL -- there are quite a few differences -- Not to be rude -- but the postgreSQL docs (the Preface, Tutorial, and SQL Language sections) would be good for you to read... -- Greg Patnude / The Digital Demention 2916 East Upper Hayden Lake Road Hayden Lake, ID 83835 (208) 762-0762 Karam Chand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello I have been working with Access and MySQL for pretty long time. Very simple and able to perform their jobs. I dont need to start a flame anymore :) I have to work with PGSQL for my companies current project. I have been able to setup postgresql in my rh box and i can connect and work with psql. I even downloaded pgadmin III so that i can get to work with a GUI interface. As I starting...I see the architecture of PGSQL is quite complex...or thats what I feelmaybe its for good :) Here are some of my doubts : 1.) What is template1 and template0? I assume these are system databases. Am I right? 2.) When I create a database using CREATE DATABASE stmt. a new DB is created where it has 4 schemas and around 100 tables. These are the system tables keeping information about everything in the database? I hope I am correct :) 3.) To get all the database is the server we use query like - select datname from pg_database I means that there exists a table pg_database in all the database and all the pg_database table(s) are updated whenever a user issues CREATE DATABASE stmt. Why I am saying so coz in PgAdmin III i can see these tables in all the databases? 4.) I couldnot find any query to change the context of database like in MySQL : use database; or am i missing something? 5.) In MySQL, there are many command like show tables, show databases etc. to get object details. I cant see anything similar in PGSQL. After searching the net i find that i have to execute certain queries to fetch those queries. Is this the only way? Any help would be appreciated. Regards Karam __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
Karam Chand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 5.) In MySQL, there are many command like show tables, show databases etc. to get object details. I cant see anything similar in PGSQL. After searching the net i find that i have to execute certain queries to fetch those queries. Is this the only way? One easy way is to use the psql command line program and the \d command. It lists all your tables, lists all the columns in a table, etc. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Ed Loehrwrote:
I believe DBI/DBD does this for you:
while ($row_href = $sth-fetchrow_hashref)
{
push( @taghash, $row_href);
}
Don't do that! Each hashref in that array will point to the same hash in some
future version of the DBI. You should do this instead:
while($row=$sth-fetchrow_hashref){
push @taghash,{%$row};
}
Or, better yet:
$taghash=$sth-fetchall_arrayref({});
to get everything all in one go.
--
Peter Haworth [EMAIL PROTECTED]
"Master, does Emacs have the Buddha nature?" the novice asked.
The Chief Priest had been in the temple for many years and could be
relied upon to know these things. He thought for several minutes before
replying, "I don't see why not. It's got bloody well everything else."
[GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Hello, I'm trying to move from mySQL to PostgreSQL, and I've got to port a
web app over that's written in perl. It uses the DBD/DBI stuff, and works
great so far with mySQL. I've got a very specific question relating to
pulling data out of a database, I hope this is the correct forum for it.
Here goes:
I have a database set up with a table that has 3 fields in it:
userid
username
userdata
In my current code (perl/mySQL), I execute the following query: "SELECT *
from table_name" - then use the following code to put it in a hash:
$j = 0;
while (@row = $sth-fetchrow_array)
{
for ($i = 0; $i $fields; $i++)
{
$taghash[$j]{$$fieldnames[$i]} = $row[$i];
}
$j++;
}
What I end up with is an array of hashes containing all the table data.
Each element in the array is a hash called $taghash[$i], and the fields can
be accessed via $taghash[$i]{'userid'}, $taghash[$i]{'username'}, and
$taghash[$i]{'userdata'}. $fields and $fieldnames are variables created by a
subroutine I wrote which is called after the query is executed. $fields is
simply the number of fields in the table, and $fieldnames is an array
containing the names of the columns in the table, in order, produced by
"$fieldnames = $sth-{NAME};" HERE is the problem. The PostgreSQL DBI/DBD
doesn't seem to support this. I'm looking for something that returns the
names of the columns in the table, so I can duplicate my code without
changing too much. Is there anything available to do this? I've yet to find
it in the documentation, though I may have simply missed it, as I'm new to
PostgreSQL... Any help is appreciated...
Thanks,
Matt ([EMAIL PROTECTED])
Re: [GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Matt Housh wrote:
In my current code (perl/mySQL), I execute the following query: "SELECT *
from table_name" - then use the following code to put it in a hash:
$j = 0;
while (@row = $sth-fetchrow_array)
{
for ($i = 0; $i $fields; $i++)
{
$taghash[$j]{$$fieldnames[$i]} = $row[$i];
}
$j++;
}
What I end up with is an array of hashes containing all the table data.
Each element in the array is a hash called $taghash[$i], and the fields can
be accessed via $taghash[$i]{'userid'}, $taghash[$i]{'username'}, and
$taghash[$i]{'userdata'}. $fields and $fieldnames are variables created by a
subroutine I wrote which is called after the query is executed. $fields is
simply the number of fields in the table, and $fieldnames is an array
containing the names of the columns in the table, in order, produced by
"$fieldnames = $sth-{NAME};" HERE is the problem. The PostgreSQL DBI/DBD
doesn't seem to support this. I'm looking for something that returns the
names of the columns in the table, so I can duplicate my code without
changing too much. Is there anything available to do this? I've yet to find
it in the documentation, though I may have simply missed it, as I'm new to
PostgreSQL... Any help is appreciated...
I believe DBI/DBD does this for you:
while ($row_href = $sth-fetchrow_hashref)
{
push( @taghash, $row_href);
}
Regards,
Ed Loehr
