Hi,
I did just think of something we could improve though. The pattern
selectivity code doesn't make any use of the statistics about most
common values. For a constant pattern, we could actually apply the
pattern test with each common value and derive answers that are exact
for the portion of
At 12:23 PM 1/9/2006, peter royal wrote:
On Jan 8, 2006, at 4:35 PM, Ron wrote:
Areca ARC-1220 8-port PCI-E controller
Make sure you have 1GB or 2GB of cache. Get the battery backup and
set the cache for write back rather than write through.
The card we've got doesn't have a SODIMM
Hello,
I have to develop a companies search engine (looks like the Yellow
pages). We're using PostgreSQL at the company, and the initial DB is
2GB large, as it
has companies from the entire world, with a fair amount of information.
What reading do you suggest so that we can develop the search
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
Alessandro Baretta [EMAIL PROTECTED] writes:
I have no clue as to how or why the statistics were wrong
yesterday--as I vacuum-analyzed continuously out of lack of any better
idea--and I was stupid enough to re-timestamp everything before
selecting from pg_stats.
Too bad. I would be
When grilled further on (Mon, 9 Jan 2006 22:58:18 -0700),
Michael Fuhr [EMAIL PROTECTED] confessed:
On Mon, Jan 09, 2006 at 09:23:38PM -0700, Robert Creager wrote:
I'm working with a query to get more info out with a join. The base
query works great speed wise because of index usage. When
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://klive.cpushare.com/2.6.15/ . That's the
string that is being searched against
Andrea Arcangeli [EMAIL PROTECTED] writes:
There's only one preempt near the end, not sure if it would work?
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.
regards,
Matteo Beccati [EMAIL PROTECTED] writes:
I did just think of something we could improve though. The pattern
selectivity code doesn't make any use of the statistics about most
common values. For a constant pattern, we could actually apply the
pattern test with each common value and derive
On Tue, 2006-01-10 at 12:49 -0500, Tom Lane wrote:
Matteo Beccati [EMAIL PROTECTED] writes:
I did just think of something we could improve though. The pattern
selectivity code doesn't make any use of the statistics about most
common values. For a constant pattern, we could actually apply
Simon Riggs [EMAIL PROTECTED] writes:
I think its OK to use the MCV, but I have a problem with the current
heuristics: they only work for randomly generated strings, since the
selectivity goes down geometrically with length.
We could certainly use a less aggressive curve for that. You got a
On Tue, 2006-01-10 at 17:21 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think its OK to use the MCV, but I have a problem with the current
heuristics: they only work for randomly generated strings, since the
selectivity goes down geometrically with length.
We could
Ron,
A few days back you mentioned:
Upgrade your kernel to at least 2.6.12
There's a known issue with earlier versions of the 2.6.x kernel and
64b CPUs like the Opteron. See kernel.org for details.
I did some searching and couldn't find any obvious mention of this issue
(I gave up after
Hello,
I have an inner join query that runs fast, but I when I
change to a left join the query runs 96 times slower. I wish I could always do an inner join,
but there are rare times when there isnt data in the right hand
table. I could expect a small
performance hit, but the difference
Simon Riggs [EMAIL PROTECTED] writes:
I meant use the same sampling approach as I was proposing for ANALYZE,
but do this at plan time for the query. That way we can apply the
function directly to the sampled rows and estimate selectivity.
I think this is so unlikely to be a win as to not even
On Tue, 10 Jan 2006, Charles A. Landemaine wrote:
Hello,
I have to develop a companies search engine (looks like the Yellow
pages). We're using PostgreSQL at the company, and the initial DB is
2GB large, as it
has companies from the entire world, with a fair amount of information.
What
Dave Dutcher [EMAIL PROTECTED] writes:
I have an inner join query that runs fast, but I when I change to a left
join the query runs 96 times slower.
This looks like an issue that is fixed in the latest set of releases,
namely that OUTER JOIN ON conditions that reference only the inner
side of
Ok, I'm back, and in a little better shape.
The query is now correct, but still is slow because of lack of index usage. I
don't know how to structure the query correctly to use the index.
Taken individually:
weather=# explain analyze select * from doy_agg where doy = extract( doy from
now()
At 07:28 PM 1/10/2006, Mark Lewis wrote:
Ron,
A few days back you mentioned:
Upgrade your kernel to at least 2.6.12
There's a known issue with earlier versions of the 2.6.x kernel and
64b CPUs like the Opteron. See kernel.org for details.
I did some searching and couldn't find any
On Tue, Jan 10, 2006 at 10:10:55PM -0700, Robert Creager wrote:
The query is now correct, but still is slow because of lack of
index usage. I don't know how to structure the query correctly to
use the index.
Have you tried adding restrictions on doy in the WHERE clause?
Something like this, I
20 matches
Mail list logo
