Is there a TODO here?
---
Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > ... Introducing a new query execution step sounds
> > like a better/easier idea than was I was going to do, which was to
> > rewo
On Wed, 2004-05-19 at 12:55, Tom Lane wrote:
> "Glen Parker" <[EMAIL PROTECTED]> writes:
> > What am I missing? Why is a performance bottle neck of this magnitude not
> > on the same list of priorities as PITR, replication, and Win32?
>
> It's higher on my personal to-do list than most of those ;
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> ... Introducing a new query execution step sounds
> like a better/easier idea than was I was going to do, which was to
> rework some of the access methods to operate on vectors instead of
> scalars. That idea looks increasingly difficult to implemen
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> > Or:
> > 2. Sort AND COPY TID's into physical order.
> > 3. Read heap in phy. order, match results to un-sorted TID list.
> > That sounds quite cheap.
>
> No, it sounds like handwaving. Wh
"Glen Parker" <[EMAIL PROTECTED]> writes:
> What am I missing? Why is a performance bottle neck of this magnitude not
> on the same list of priorities as PITR, replication, and Win32?
It's higher on my personal to-do list than most of those ;-). But those
things are getting done because there ar
On Wed, 2004-05-19 at 11:56, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > Are you saying that index scan results are sorted by something other
> > than the index key? Because in my scheme they would still be sorted by
> > index key.
>
> Not unless you add yet another sort
"Glen Parker" <[EMAIL PROTECTED]> writes:
>> Not unless you add yet another sort step after the fetch step, that is
>> the idea becomes
>> 1. read index to get candidate TIDs
>> 2. sort TIDs into physical order
>> 3. read heap in physical order, check row visibility
>> 4. sort selected rows into in
On Wed, 2004-05-19 at 13:10, Tom Lane wrote:
> "Glen Parker" <[EMAIL PROTECTED]> writes:
> >> Not unless you add yet another sort step after the fetch step, that is
> >> the idea becomes
> >> 1. read index to get candidate TIDs
> >> 2. sort TIDs into physical order
> >> 3. read heap in physical ord
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> No doubt, you can't just naively create giant vectors of TIDs and expect
> to sort them. Is there any concept in Pg of an unrealized result?
Only for the case of a partially-read plan result. That is, we do this
for rowsets, but not for scalars or
Tom Lane <[EMAIL PROTECTED]> writes:
> The main thing that unordered indexscan could do for us is extend the
> usefulness of indexscan plans into relatively-poor-selectivity cases
> where we presently tend to drop back to seqscans.
Well I'm sure Tom remembers this since he's mentioned it in th
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> Sent: Wednesday, May 19, 2004 11:56 AM
> Not unless you add yet another sort step after the fetch step, that is
> the idea becomes
> 1. read index to get candidate TIDs
> 2. sort TID
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> For starters, read the previous discussions of this in the archives.
Search doesn't work. Even if it did, I'm not sure what I would search on.
Do you remember the time frame of the discussion?
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> Are you saying that index scan results are sorted by something other
> than the index key? Because in my scheme they would still be sorted by
> index key.
Not unless you add yet another sort step after the fetch step, that is
the idea becomes
On Wed, 2004-05-19 at 07:58, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > We have noticed a way to make a major improvement in Pg's performance on
> > our workload, and I would like to get your thoughts before I go off to
> > work up a patch.
>
> For starters, read the prev
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> For starters, read the previous discussions of this in the
Tom> archives.
Tom> Two questions you should have answers to before starting to
Tom> implement, rather than after, are how to deal with locking
Tom> consideratio
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> We have noticed a way to make a major improvement in Pg's performance on
> our workload, and I would like to get your thoughts before I go off to
> work up a patch.
For starters, read the previous discussions of this in the archives.
Two questions
> The basic problem is that Pg seeks far too much when performing an index
> scan. I have saved an strace of a backend which is selecting 170,000
> rows from a 240,000,000 row table via index scan. The strace shows
> 134,000 seeks and reads, or almost one seek for every tuple in the
> result set.
Yes, fetching a RID list from an index scan, sorting 'em and then
fetching from the table would be a very appreciable speedup for many
queries. I would imagine that all the commercial engines do this (db2
calls it a sorted RID-list-fetch) .. and this has in fact been
discussed on -hackers before.
Greetings all,
We have noticed a way to make a major improvement in Pg's performance on
our workload, and I would like to get your thoughts before I go off to
work up a patch.
The basic problem is that Pg seeks far too much when performing an index
scan. I have saved an strace of a backend which
19 matches
Mail list logo
