Re: Discarding the resulting rows - Mailing list pgsql-hackers
From | Murali M. Krishna |
---|---|
Subject | Re: Discarding the resulting rows |
Date | |
Msg-id | 146661.38681.qm@web52803.mail.re2.yahoo.com Whole thread Raw |
In response to | Re: Discarding the resulting rows (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
<table border="0" cellpadding="0" cellspacing="0"><tr><td style="font: inherit;" valign="top"><br /><br />Hello All:<br /><br/>The optimizer assumes that data is disk resident when computing the cost of a query plan.<br />I am trying to ascertainwhat the correlation is between times and costs of some benchmark queries to see how good the cost model is.<br/><br />Since I have more than 100 queries, it would be painful to stop and start the server each time to force allthe buffer pages out. Also, some of these queries have large number of result rows. I don't want the time to be skewedby the output time.<br /><br />Cheers,<br /><br />Murali.<br /><br /><br /><br />-----------------------------------------------------------------<br/>Please visit <a href="http://NumberFest.com" rel="nofollow"target="_blank">NumberFest.com</a> for educational number puzzles & mind exercises for all ages! And pleasetell your friends about it. Thank You!<br /><br /><br />--- On <b>Mon, 4/26/10, Tom Lane <i><tgl@sss.pgh.pa.us></i></b>wrote:<br /><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left:5px; padding-left: 5px;"><br />From: Tom Lane <tgl@sss.pgh.pa.us><br />Subject: Re: [HACKERS] Discardingthe resulting rows<br />To: "Jaime Casanova" <jcasanov@systemguards.com.ec><br />Cc: "Robert Haas" <robertmhaas@gmail.com>,"Kevin Grittner" <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org, "MuraliM. Krishna" <murali1729@yahoo.com><br />Date: Monday, April 26, 2010, 1:25 PM<br /><br /><div class="plainMail">JaimeCasanova <<a href="/mc/compose?to=jcasanov@systemguards.com.ec" ymailto="mailto:jcasanov@systemguards.com.ec">jcasanov@systemguards.com.ec</a>>writes:<br />> On Mon, Apr 26, 2010at 3:03 PM, Robert Haas <<a href="/mc/compose?to=robertmhaas@gmail.com" ymailto="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br />>> On Mon, Apr 26, 2010 at 3:36 PM,Kevin Grittner<br />>> <<a href="/mc/compose?to=Kevin.Grittner@wicourts.gov" ymailto="mailto:Kevin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>>wrote:<br />>>> I would use EXPLAINANALYZE SELECT ...<br />>> <br />>> There's some overhead to that, of course.<br /><br />> he couldsee the "actual time" in the very first row of the EXPLAIN<br />> ANALYZE... isn't that a value that is more closeto what the OP is<br />> looking for?<br /><br />Well, it will include the instrumentation overhead of EXPLAIN ANALYZE,<br/>which can be nontrivial depending on your hardware and the query plan.<br /><br />On the other hand, EXPLAINskips the cost of converting the result data<br />to text form, not to mention the network overhead of deliveringit; so<br />in another sense it's underestimating the work involved.<br /><br />I guess the real question is exactlywhat the OP is hoping to measure<br />and why.<br /><br /> regards, tom lane<br /><br />-- <br />Sent viapgsql-hackers mailing list (<a href="/mc/compose?to=pgsql-hackers@postgresql.org" ymailto="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/>To make changes to your subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></div></blockquote></td></tr></table><br />
pgsql-hackers by date: