No. **No gain at all**. [The manual explicitly states][1]:

> Tip: **There is no performance difference among these three types**, apart
> from increased storage space when using the blank-padded type, and a
> few extra CPU cycles to check the length when storing into a
> length-constrained column. While `character(n)` has performance
> advantages in some other database systems, there is no such advantage
> in PostgreSQL; in fact `character(n)` is usually the slowest of the
> three because of its additional storage costs. **In most situations `text`
> or `character varying` should be used instead**.

`char(n)` is a largely outdated, useless type. Stick with `varchar(n)`. If you don't need to enforce the length, `varchar` or `text` would be a tiny bit faster. 
You won't be able to measure a difference.

Also, if all strings are exactly 36 characters in length, there is **no** storage saving either way, not even a minuscule one. Both have exactly the same size on disk and in RAM. You can test with [`pg_column_size()`][2] (on an expression and on a table column).

Related:

- [Any downsides of using data type “text” for storing strings?][3]

You didn't ask for **other options**, but I'll mention two:

- [**`COLLATION`**][4] - unless you are running your DB with the ["C" collation][5]. Collation is often overlooked and possibly expensive. Since your strings don't seem to be meaningful in a natural language, there is probably no point in following `COLLATION` rules. Related:
 - http://dba.stackexchange.com/questions/49540/how-do-i-efficiently-get-the-most-recent-corresponding-row/49555#49555
 - http://dba.stackexchange.com/questions/82420/execute-within-function-not-using-index/82508#82508

 Extensive benchmark comparing (among other) the effect of `COLLATE "C"` on performance:
 - [Slow query ordering by a column in a joined table][6]

- [**UUID**][7], obviously. Your string suspiciously looks like a UUID (32 hex digits plus 4 delimiters). It would be much more effective to store these as actual `uuid` data type, which is faster in multiple ways and only occupies **16** bytes (as opposed to **37** bytes for either `char(36)` or `varchar(36)`. `COLLATION` would be irrelevant, too.

        SELECT '922475bb-ad93-43ee-9487-d2671b886479'::uuid


  [1]: http://www.postgresql.org/docs/current/interactive/datatype-character.html
  [2]: http://www.postgresql.org/docs/current/interactive/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE
  [3]: http://stackoverflow.com/a/20334221/939860
  [4]: http://www.postgresql.org/docs/current/interactive/collation.html
  [5]: http://www.postgresql.org/docs/current/interactive/locale.html
  [6]: http://stackoverflow.com/a/9908333/939860
  [7]: http://www.postgresql.org/docs/current/interactive/datatype-uuid.html