Hi,
I am having trouble understanding why a seqscan is chosen for this query.
In practice the seqscan is very expensive, whereas the nested loop is usually
quite fast, even with several hundred rows returned from meta_keywords_url.
The server is running version 8.1.3, and both tables were
Brian Herlihy [EMAIL PROTECTED] writes:
I am having trouble understanding why a seqscan is chosen for this query.
As far as anyone can see from this output, the planner's decisions are
correct: it prefers the plans with the smaller estimated cost. If you
want us to take an interest, provide
I am about to pull the trigger on a new machine after analyzing some
discussions I posted here last year. I've been trying to spec out a reliable
and powerfull enough machine where I won't have to replace it for some time.
Currently I've been using a dual Xeon 3.06ghz with 4GB of ram and
Hello All,
I'm a performance engineer, quite interested in getting deep into the PGSQL
performance enhancement effort. In that regard, I have the following
questions :
1. Is there a benchmarking setup, that I can access online?
2. What benchmarks are we running , for performance numbers?
3. What
Have you tried pgbench yet?
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 2/14/07, Krishna Kumar [EMAIL PROTECTED] wrote:
Hello All,
I'm a performance engineer, quite interested in getting deep into the
PGSQL performance enhancement effort. In that regard, I have the following
On 2/14/07, Tom Lane [EMAIL PROTECTED] wrote:
There are two things wrong here: first, that the estimated row count is
only 20% of actual; it should certainly not be that far off for such a
simple condition. I wonder if your vacuum/analyze procedures are
actually working. Second, you mentioned
Here¹s one:
Insert performance is limited to about 10-12 MB/s no matter how fast the
underlying I/O hardware. Bypassing the WAL (write ahead log) only boosts
this to perhaps 20 MB/s. We¹ve found that the biggest time consumer in the
profile is the collection of routines that ³convert to datum².
On 2/14/07, Luke Lonergan [EMAIL PROTECTED] wrote:
Here's one:
Insert performance is limited to about 10-12 MB/s no matter how fast the
underlying I/O hardware. Bypassing the WAL (write ahead log) only boosts
this to perhaps 20 MB/s. We've found that the biggest time consumer in the
Merlin Moncure wrote:
On 2/14/07, Tom Lane [EMAIL PROTECTED] wrote:
There are two things wrong here: first, that the estimated row
count is only 20% of actual; it should certainly not be that far
off for such a simple condition. I wonder if your vacuum/analyze
procedures are actually working.
Thanks Claus thats good news!
I'm having a reputable vendor build the box and test it for me before
delivering. The bottom line of your message, did you mean 'should be not a
problem'? I wonder what the main reason for your improvement, your ram was
increased by a factor of 2, but 4 way
Mark Stosberg [EMAIL PROTECTED] writes:
Your suggestion about the pet_state index was right on. I tried
Analyze on it, but still got the same bad estimate. However, I then
used reindex on that index, and that fixed the estimate accuracy,
which made the query run faster!
No, the estimate is
Paul,
On 2/14/07, Paul Ramsey [EMAIL PROTECTED] wrote:
You'll find that PostGIS does a pretty good job of selectivity
estimation.
PostGIS is probably what I'm going to experiment in the future. The
only problem is that it's really big for a very basic need.
With my current method, I don't
Hi Merlin,
On 2/14/07 8:20 AM, Merlin Moncure [EMAIL PROTECTED] wrote:
I am curious what is your take on the maximum insert performance, in
mb/sec of large bytea columns (toasted), and how much if any greenplum
was able to advance this over the baseline. I am asking on behalf of
another
Approx. 200 reqest a sec. should be a problem unless the queries are heavy.
Thanks Claus thats good news!
I'm having a reputable vendor build the box and test it for me before
delivering. The bottom line of your message, did you mean 'should be not a
problem'? I wonder what the main reason
On Wed, Feb 14, 2007 at 01:07:23PM -0500, Tom Lane wrote:
Mark Stosberg [EMAIL PROTECTED] writes:
Your suggestion about the pet_state index was right on. I tried
Analyze on it, but still got the same bad estimate. However, I then
used reindex on that index, and that fixed the estimate
On Tuesday 13 February 2007 14:51, Tom Lane wrote:
Chuck D. [EMAIL PROTECTED] writes:
It is still using that sequence scan on the view after the APPEND for the
us_city and world_city table. Any reason why the view won't use the
indexes when it is JOINed to another table but it will when
unless you specify otherwiise, every insert carries its own transaction
begin/commit. That's a lot of overhead for a single insert, no? Why
not use a single transaction for, say, each 1000 inserts? That would
strike a nice balance of security with efficiency.
pseudo code for the insert:
Begin
Hi Tom,
Sorry, I didn't ask the right question. I meant to ask Why does it estimate a
smaller cost for the seqscan?
With some further staring I was able to find the bad estimate and fix it by
increasing the relevant statistics target.
Thanks,
Brian
- Original Message
From: Tom Lane
18 matches
Mail list logo
