Skip site navigation (1) Skip section navigation (2)

Re: SSI modularity questions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI modularity questions
Date: 2011-06-28 21:33:03
Message-ID: 4E0A0240020000250003ECDA@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas  wrote:
> On 28.06.2011 20:47, Kevin Grittner wrote:
 
> Hmm, the calls in question are the ones in heapgettup() and
> heapgettup_pagemode(), which are subroutines of heap_getnext().
> heap_getnext() is only used in sequential scans, so it seems safe
> to remove those calls.
 
I haven't found anything to the contrary, if I understand correctly,
Dan found the same, and all the tests pass without them.  Here's a
patch to remove them.  This makes the recently-added
rs_relpredicatelocked boolean field unnecessary, so that's removed in
this patch, too.
 
>> I would like to add a test involving a lossy bitmap scan. How many
>> rows are normally needed to force a bitmap scan to be lossy?
> 
> The size of bitmaps is controlled by work_mem, so you can set
> work_mem very small to cause them to become lossy earlier. Off the
> top of my head I don't have any guesstimate on how many rows you
> need.
> 
>> What's the easiest way to check whether a plan is going to use (or
>> is using) a lossy bitmap scan?
> 
> Good question. There doesn't seem to be anything in the EXPLAIN
> ANALYZE output to show that, so I think you'll have to resort to
> adding some elog()s in the right places.
 
OK, thanks.
 
-Kevin



Attachment: ssi-seqscan-cleanup.patch
Description: application/octet-stream (2.1 KB)

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2011-06-28 21:33:06
Subject: Re: spinlock contention
Previous:From: Peter EisentrautDate: 2011-06-28 21:31:35
Subject: Re: marking old branches as no longer maintained

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group