The following query was successful for me:
SELECT A.id AS a_id, encode(A.account,'hex') AS a_hex,
S.id AS s_id, S.timestamp AS s_timestamp, S.summary AS s_summary
FROM ati A
JOIN summaries S ON A.summary = S.id
WHERE (A.account = '\x39fc4ea5015885d50c7730852b4a9b2249aaf54f0abb8a8ec44b7877666890d1')
ORDER BY S.timestamp DESC LIMIT 10;
Just changing the address in your query.
If it doesn’t work for you then there could be an issue with your database. Note that the node only logs transactions in the database from (finalized) blocks that it receives after being started. This means that transactions from blocks that were already finalized in your nodes database when you started logging won’t be present.
If you need a log of all historic transactions, then you should start a node with logging with a clean node database (i.e. removing the database-v4 directory) and a clean postgres database. This should ensure all historic transactions are logged, once the node catches up with the chain.
Otherwise, if your node is correctly configured, it should at least log the transactions that are finalized since was started.
On the binary data vs. hex string question, if you compare ati.account = '39fc4ea5015885d50c7730852b4a9b2249aaf54f0abb8a8ec44b7877666890d1' then it will not work as desired because the hex string on the right will be encoded. But
ati.account = '\x39fc4ea5015885d50c7730852b4a9b2249aaf54f0abb8a8ec44b7877666890d1' does work because the \x causes it to be intrepreted as a hexadecimal representation of the value of a byte array. (This assumes that your postgres version is at least 10.)
transaction-outcome=# SELECT decode('39fc4ea5015885d50c7730852b4a9b2249aaf54f0abb8a8ec44b7877666890d1','hex') = '\x39fc4ea5015885d50c7730852b4a9b2249aaf54f0abb8a8ec44b7877666890d1';
?column?
----------
t
(1 row)