If I'm understanding you correctly, it may actually start sending rows before the query is finished. Does this mean it may say it takes 2 seconds to perform the query, but I may actually have the initial rows in 100-500ms?
I am going to disagree with Dave, because as far as I can see he's talking about transaction isolation, which is all about when changes to data become permanent, rather than when data can be returned.
The answer I like is, "It depends."
As a general rule, the first row should be returned as soon as it can be returned, although optimisation and efficiency considerations may cause (some) deferral.
Take a simple, unordered query
SELECT * FROM someTable;
Move the disk head to the start of someTable, read the first block of data and the server has done all it needs to do, to be able to return the first row. If someTable is occupying hundreds of blocks, and the client is on the other end of a network, the server might as well write the first row(s) into the network transmit buffer, while it waits for the disk head to continue moving and reading more of the blocks which contain someTable.
Adjust the query to be an ordered list
SELECT * FROM someTable ORDER BY someField DESC;
Move the disk head to the start of someTable, read the first block. Can the server return the first row? No it can't. All rows of someTable will have to be read (scanned), before any row can be placed in order and the first row returned
Introduce a calculated field
Select A, B, (A + B) as Total FROM someTable ORDER BY Total DESC;
Now we have a choice. Is it quicker to scan the entire table, have the CPU do the maths for every row, scan the results, place the first row in order and return it. Or, read the first block of some table, do the maths for each row in the first block, read the second block etc.
The answer is, "It depends." It depends how much and what data is in the table, how fast the disk head can move to it, how long the CPU takes to do the calculations, how much RAM is available - If there isn't enough RAM to hold the table, the disk heads going to have to move (even) more, as the interim results need to be written to a temporary file.
Adding grouping and joining clauses, using indexes, the number of possibly 'best' outcomes rises. The more complex the query becomes, the more scope there is to optimise how the results are arrived at and the more scope there is, for different database engines to behave differently.
To try to predict the most efficient way to scan the tables and assemble the results of a particular query, we need some sort of 'query plan' . Which is roughly what EXPLAIN does in Postgres. EXPLAIN performs a dry run on the query and tells you how the engine is likely to process it and what each step will cost in time and resource. Using EXPLAIN ANALYZE with Postgres, changes the dry run to a live run, which may change the results dramatically.
I should point out I have a lot more practical experience as a dba with MS SQL than with Postgres. From what I recall, the timing information presented by a query plan, is an estimation of completion of the query at the server. It does not include transmission (to the client) or any deferral made at the client.
To reiterate the original answer. In most cases (I can think of) the first row should be returned as soon as it can be returned; which may be some time before the last row can be returned. RS has a quirky threading model, which presents scope for RS to defer availability of the first row and I have never tested that.
So the other answer I like is, "Try it and see."