When i test select * from myFederatedTable (for test there is 50k rows) it take 0.3732 seconds
now I have two federated tables with data < 20000 in both tables, and have query like :

SELECT i.id_news, i.id_news_type, i.id_agency, i.add_date, i.update_date, j.title, k.image_name_latin, m.folder_path
FROM tbl i
INNER JOIN tbl_languages j on i.id_news = j.id_news and j.lang = 'en'
INNER JOIN federated_Table1 k on i.id_image_groups = k.id_image_groups
INNER JOIN federated_table2 m on k.id_folder_groups = m.id_folder_groups
ORDER BY i.update_date DESC
LIMIT 14


It takes 16 seconds

Without joins to federated tables 

SELECT i.id_news, i.id_news_type, i.id_agency, i.add_date, i.update_date, j.title
    FROM tbl i
    INNER JOIN tbl_languages j on i.id_news = j.id_news and j.lang = 'en'
    ORDER BY i.update_date DESC
    LIMIT 14


0.0496 seconds.
I have few questions


1.Is there any way to optimize it ?
2.when i select from federated table (really i select from main database?) or when i join to federated table I really join to main database?
3.Task is copy data from one database tables to another database tables. Is there best way to replicate this 2 tables for quick
selection ?


"It depends".

If the client vanishes due to network connection loss the query will generally run until it's retrieved enough rows to fill its network send buffer, then stop and get stuck until the TCP connection drops, at which point it'll abort. If it completes before it fills the TCP send buffer it'll complete successfully, so if it's autocommit the query will commit.

If the client is killed in a way that the client's operating system can report to the server via a TCP RST (like a client segfault/crash, SIGTERM, SIGKILL, etc), the PostgreSQL server will set the interrupt flag. Next time the query checks for interrupts as it executes it will see the flag and abort. Sometimes a query might be doing CPU-heavy work within code that doesn't check for interrupts - some extensions, and a few places within the PostgreSQL core - in which case it might not notice the interrupt for a long time and keep on running. It'll pretty much always see the interrupt and abort before completing and committing if it's autocommit, though.

If the client is killed by something like a sudden OS reboot, so that the client host suddenly knows nothing about the TCP connection but can still respond on the network, the query will probably get aborted the first time it triest to write a row, like Jeff said, because the client's host will send a TCP RST in response to the first packet sent by the server after the reboot. PostgreSQL checks for interrupts at each row it sends.

This behavour isn't configurable. As far as PostgreSQL is concerned if the client goes away its job is to terminate any queries the client was running.  To change that you'd need some kind of query completion token that you could obtain at query start, then use to ask the server about the query via another connection later. Essentially you'd have to implement asynchronous/background queries. Possibly a nice feature, but not currently supported.

If the query is autocommit, or if your query was a COMMIT that was in-flight at the time you killed the client/lost the connection, it is possible for a transaction to be in an indeterminate state where the client doesn't know whether or not it committed. There's no real way to find out, other than looking for the effects of the transaction on the data.

Where that is unacceptable you can use two phase commit and a client-side transaction manager.
