From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: gistchoose vs. bloat |
Date: | 2013-01-24 20:35:24 |
Message-ID: | 24647.1359059724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
> There is another cause of overhead when use randomization in gistchoose:
> extra penalty calls. It could be significant when index fits to cache. In
> order evade it I especially change behaviour of my patch from "look
> sequentially and choose random" to "look in random order". I think we need
> to include comparison of CPU time.
Hmm ... actually, isn't that an argument in favor of Heikki's method?
The way he's doing it, we can exit without making additional penalty
calls once we've found a zero-penalty tuple and decided not to look
further (which is something with a pretty high probability).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-01-24 20:37:25 | Re: Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve |
Previous Message | Tom Lane | 2013-01-24 20:17:28 | Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |