On Fri, 2005-05-20 at 15:23 -0700, Josh Berkus wrote:
> > Well, that raises an interesting issue, because AFAIK none of the cost
> > estimate functions currently do that. Heck, AFAIK even the piggyback
> > seqscan code doesn't take other seqscans into account.
>
> Sure. But you're striving for g
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Does this sound like a reasonable approach? Also, how important do
> people think it is to use explain analyze output instead of just doing
> SELECT count(*) FROM (query you actually want to test)? (The select
> count(*) wrapper is just a means to throw
On Fri, May 20, 2005 at 03:23:16PM -0700, Josh Berkus wrote:
> Jim,
>
> > Well, that raises an interesting issue, because AFAIK none of the cost
> > estimate functions currently do that. Heck, AFAIK even the piggyback
> > seqscan code doesn't take other seqscans into account.
>
> Sure. But you'
On Fri, May 20, 2005 at 04:47:38PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote:
> >> can test our formula for accuracy and precision. However, such a formula
> >> *does* need to take into account concurrent ac
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote:
>> can test our formula for accuracy and precision. However, such a formula
>> *does* need to take into account concurrent activity, updates, etc ... that
>> is, it needs to approximately es
On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote:
> > In the
> > case of testing index scans, we need to be able to vary correlation,
> > which so far I've been doing by ordering by different columns. I suspect
> > it will also be important to test with different tuple sizes. There's
> >
Tom,
> for rec in explain analyze ... loop
> insert into table values(rec."QUERY PLAN");
> end loop;
I need to go further than that and parse the results as well. And preserve
relationships and nesting levels.
H ... what's the indenting formula for nesting leve
Josh Berkus writes:
> I think a first step would be, in fact, to develop a tool that allows us to
> put EXPLAIN ANALYZE results in a database table. Without that, there is no
> possibility of statistical-scale analysis.
AFAIK you can do that today using, eg, plpgsql:
for rec in explai
Jim,
> I've been doing some work to try and identify the actual costs
> associated with an index scan with some limited sucess. What's been run
> so far can be seen at http://stats.distributed.net/~decibel. But there's
> a couple problems. First, I can't use the box exclusively for this
> testing,
