From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning time in explain/explain analyze |
Date: | 2014-01-09 21:14:10 |
Message-ID: | 17920.1389302050@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> However I don't see the issue here. Two gettimeofday calls per query
> plan is not really going to hurt even on systems where it's slow.
I tend to agree with this, especially if the calls only occur when the
user asks for the information (ie, does an EXPLAIN rather than just
executing the query).
> The only way two gettimeofday calls per query plan becomes an issue is
> if you're executing non-cached queries repeatedly on data that's
> entirely in ram. That means the query processing is entirely cpu-bound
> and adding two syscalls could actually be noticeable. The mitigation
> strategy would be to prepare and cache the query handle to execute it
> again.
This point weighs against the proposal that we time the work to fetch
a previously-prepared query plan; if we do that then the "mitigation
strategy" doesn't mitigate anything.
In short then, I think we should just add this to EXPLAIN and be done.
-1 for sticking the info into PlannedStmt or anything like that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-01-09 21:25:08 | Re: Turning off HOT/Cleanup sometimes |
Previous Message | Steeve Lennmark | 2014-01-09 21:10:20 | Re: [PATCH] Relocation of tablespaces in pg_basebackup |