I'm wondering if these types of the identical or maybe there's some difference.

Method 1:

CREATE TABLE testtable
(
   id serial, 
   title character varying, 
   CONSTRAINT id PRIMARY KEY (id)
);

Method: 2

CREATE TABLE testtable
(
   id serial PRIMARY KEY, 
   title character varying, 
);

Method 3:

CREATE TABLE testtable
(
   id integer PRIMARY KEY, 
   title character varying, 
);

CREATE SEQUENCE testtable_id_seq
    START WITH 1
    INCREMENT BY 1
    NO MAXVALUE
    NO MINVALUE
    CACHE 1;

ALTER SEQUENCE testtable_id_seq OWNED BY testtable.id;

Update: I discovered something on the internet stating that using a raw sequence you are able to pre-allocate memory for primary secrets which will help should you intend on doing several 1000 card inserts within the next minute.

Check it out and find out take away the trailing "," after "different" around the second and third so that they run, execute all of them, then do:

\d testtable

after each one of these and you will see what goes on. Then drop the table and start the next. It may be like this:

 Column |       Type        |                       Modifiers                        
--------+-------------------+--------------------------------------------------------
 id     | integer           | not null default nextval('testtable_id_seq'::regclass)
 title  | character varying | 
Indexes:
    "id" PRIMARY KEY, btree (id)

 Column |       Type        |                       Modifiers                        
--------+-------------------+--------------------------------------------------------
 id     | integer           | not null default nextval('testtable_id_seq'::regclass)
 title  | character varying | 
Indexes:
    "testtable_pkey" PRIMARY KEY, btree (id)

 Column |       Type        | Modifiers 
--------+-------------------+-----------
 id     | integer           | not null
 title  | character varying | 
Indexes:
    "testtable_pkey" PRIMARY KEY, btree (id)

Third and fourth are almost identical, except the main key produced is known as in a different way. Within the third, the succession is no more completed whenever you place in to the database. You have to produce the sequence first, then produce the table such as this:

CREATE TABLE testtable
(
   id integer PRIMARY KEY DEFAULT nextval('testtable_id_seq'),
   title character varying
);

To obtain something which looks just like the 2nd one. The only real upside to that's which you can use the CACHE directive to pre-allocate some quantity of sequence amounts. It is possible for your to become a large enough resource drain you need to lower the contention. But you'd have to be doing several 1000 card inserts per second, not each minute, before that's prone to happen.

No semantic distinction between method 1 and method 2.

Method 3 is very similar, too - it's what goes on unconditionally, when utilizing serial. However, when utilizing serial, postgres also records an addiction of sequence up for grabs. So, should you drop the table produced in method one or two, the succession will get dropped too.