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**.

Bold emphasis mine.

`char(n)` is a largely outdated, useless type. Stick with `varchar(n)`. Without need to enforce a maximum length, `varchar` or `text` are a tiny bit faster, with fewer complications.

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).

And if all strings *must* have 36 characters, rather make it `text` with a `CHECK (length(col) = 36)` constraint enforcing *exact* length, not `varchar(36)` only enforcing max. length. See:

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

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

#### 1. [**`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:

- https://dba.stackexchange.com/questions/49540/how-do-i-efficiently-get-the-most-recent-corresponding-row/49555#49555
- https://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]

#### 2. [**UUID**][7]

Your string suspiciously looks like a UUID (32 hex digits separated by 4 delimiters in canonical way). It's much more efficient to store UUIDs as actual `uuid` data type: faster in multiple ways, and only occupies **16** bytes per UUID - as opposed to **37** bytes in RAM for either `char(36)` or `varchar(36)` (stored without delimiters, just the 32 defining characters), or **33** bytes on disk. But [alignment padding][8] would result in **40** bytes either way in many cases.) `COLLATION` is irrelevant for the `uuid` data type, too.

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

This may be helpful (last chapters):

- [Convert hex in text representation to decimal number][9]

See also:

- https://dba.stackexchange.com/questions/125499/what-is-the-overhead-for-varcharn/125526#125526
- https://dba.stackexchange.com/questions/115271/what-is-the-optimal-postgresql-data-type-for-an-md5-field/115316#115316


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