Selecting and copying event log entries for some machine

I have a PL/pgSQL function with erratic performance:

DECLARE
l RECORD;
events_for_machine integer;
before_event "PRD".events_log;
machines_ids integer[];
island_controller RECORD;
before_order "PRD".events_log;
before_detail "PRD".events_log;
before_pallete "PRD".events_log;
before_operation "PRD".events_log;
timer timestamp;
timer2 timestamp;

BEGIN
machines_ids = string_to_array(machines_ids_g,',')::integer[];
for l in 
select m.*
from
    "PRD".machines m
    inner join
    unnest(machines_ids) n(id) on n.id = m.id
where
    m.start_work_date = begin_date_g AND plc_time = 5000) AND (event_type_id = begin_date_g AND plc_time <= end_date_g) ORDER BY plc_time;

RAISE NOTICE 'koniec dla maszyny %',l.id;
END LOOP;

END;

Sometimes the function execution time is ~9 seconds and sometimes ~40 seconds for the same arguments.

What does it depend on? What could be so inefficient?

I find this query difficult to read to begin with. Here are my comments:

-
When you DECLARE a bunch of variables it is useful to name them such that they will be easy for another programmer to identify throughout the script. For example adding v_ in front of them is a good way. Also calling a variable just l is pretty cryptic.

-
select * is sometimes not a good idea; that is, unless you actually need all of the columns. I see you use that a lot and it could be part of your performance issues. Part of why it may be problematic is also that your result set is unpredictable, if a column is added or dropped for instance, or renamed, your query would not be repeatable. It's better to get a "column does not exist" error than get unpredictable result set. Be explicit when you can.

-
The lack of proper indenting in your script, as well as the lack of a proper explanation in your question (or as comments within your script), in addition to some of it being in Polish it seems, makes it very difficult to decrypt what you are doing here unless you provide more information.

-
You have lots of variables, most of them holding lots of data (select * into etc.). This likely is affecting performance. Multiple levels of nested subqueries can also slow it down.

StackExchange Code Review Q#19056, answer score: 3