On Tue, Jan 10, 2006 at 10:46:53AM -0500, Tom Lane wrote:
Not with that data, but maybe if you increased the statistics target for
the column to 100 or so, you'd catch enough values to get reasonable
results.
Sorry, I'm not expert with postgresql, could you tell me how to increase
the
On Wed, Jan 11, 2006 at 09:07:45AM +, Simon Riggs wrote:
I would suggest we do this only when all of these are true
- when accessing more than one table, so the selectivity could effect a
join result
FWIW my problem only happens if I join: on the main table where the
kernel_version string
On Wed, Jan 11, 2006 at 12:40:32PM -0600, Jim C. Nasby wrote:
On Tue, Jan 10, 2006 at 02:44:47AM +0100, Andrea Arcangeli wrote:
cooperative runs WHERE kernel_version NOT LIKE '%% PREEMPT %%', while
preempt runs WHERE kernel_version LIKE '%% PREEMPT %%'. The only
difference
One thing you
On Wed, Jan 11, 2006 at 09:39:47PM +0100, Andrea Arcangeli wrote:
On Wed, Jan 11, 2006 at 12:40:32PM -0600, Jim C. Nasby wrote:
On Tue, Jan 10, 2006 at 02:44:47AM +0100, Andrea Arcangeli wrote:
cooperative runs WHERE kernel_version NOT LIKE '%% PREEMPT %%', while
preempt runs WHERE
On Tue, Jan 10, 2006 at 10:11:18AM -0500, Greg Stark wrote:
Andrea Arcangeli [EMAIL PROTECTED] writes:
Fixing this with proper stats would be great indeed. What would be the
most common value for the kernel_version? You can see samples of the
kernel_version here http
Hello,
I've a performance problem with the planner algorithm choosen in a website.
See the difference between this:
http://klive.cpushare.com/?scheduler=cooperative
and this:
http://klive.cpushare.com/?scheduler=preemptive
(note, there's much less data to show with preemptive,
On Tue, Jan 10, 2006 at 10:29:05AM +0800, Christopher Kings-Lynne wrote:
UNLIKELY string LIKE '%% PREEMPT %%'
or:
LIKELY string NOT LIKE '%% PREEMPT %%'
You should be using contrib/tsearch2 for an un-anchored text search perhaps?
If I wanted to get the fastest speed possible,
On Mon, Jan 09, 2006 at 09:54:44PM -0500, Tom Lane wrote:
Extrapolating from the observation that the heuristics don't work well
on your data to the conclusion that they don't work for anybody is not
good logic. Replacing that code with a flat 50% is not going to happen
(or if it does, I'll
