Re: Performance (was: The New Slashdot Setup (includes MySql server))

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Date: 2000-05-19 22:23:26
Message-ID: 10033.958775006@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>> More generally, someone should examine the other places where
>> heap_getnext() loops occur, and see if any of them look like performance
>> bottlenecks...

> Please don't lose sequential scan stuff even when changes to
> index scan is needed because -P option of standalone postgres
> needs sequential scan for system tables.

Good point. I'd still like not to clutter the code with deciding
which kind of scan to invoke, though. Maybe we could put the
begin_xxx routine in charge of ignoring a request for an indexscan
when -P is used. (AFAIR there's no real difference for the calling
code, it sets up scankeys and so forth just the same either way, no?
We should just need a switching layer in front of heap_beginscan/
index_beginscan and heap_getnext/index_getnext...)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-05-19 22:41:32 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Hiroshi Inoue 2000-05-19 22:01:15 RE: Performance (was: The New Slashdot Setup (includes MySql server))

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-19 22:41:32 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Hiroshi Inoue 2000-05-19 22:01:15 RE: Performance (was: The New Slashdot Setup (includes MySql server))