Hullo, I have pg 8.1.3 on an 8-CPU AIX 5.3 box with 16GB of RAM, and I'm
finding that it's taking an age to CREATE INDEX on a large table:
Column | Type | Modifiers
Hi, Craig,
Craig A. James wrote:
I hope this was just a joke. You should be sure to clarify - there
might be some newbie out there who thinks you are seriously suggesting
coding major web sites in some old-fashioned compiled language.
No, but perhaps with a CMS that pregenerates static
[Apologies if this already went through. I don't see it in the archives.]
Normally one expects that an index scan would have a startup time of nearly
zero. Can anyone explain this:
EXPLAIN ANALYZE select activity_id from activity where state in (1, 10001)
order by activity_id limit 100;
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001)
order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72 rows=100 width=8) (actual
time=207356.054..207356.876 rows=100 loops=1)
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
Mike Stone
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Am Donnerstag, 30. März 2006 14:02 schrieb Steinar H. Gunderson:
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001) order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72
Am Donnerstag, 30. März 2006 14:06 schrieb Michael Stone:
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
ANALYZE as well, but the plan choice is not the point anyway.
--
Peter Eisentraut
On Thu, Mar 30, 2006 at 02:23:53PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001) order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72 rows=100 width=8) (actual
time=207356.054..207356.876 rows=100 loops=1)
-
Hi, Peter,
Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
ANALYZE as well, but the plan choice is not the point anyway.
Maybe you could add a combined Index on activity_id and state, or (if
you use this kind of query more often) a conditional
On Thu, Mar 30, 2006 at 02:31:34PM +0200, Steinar H. Gunderson wrote:
Well, it's logical enough; it scans along activity_id until it finds one with
state=1 or state=10001. You obviously have a _lot_ of records with low
activity_id and state none of these two, so Postgres needs to scan all
Am Donnerstag, 30. März 2006 14:31 schrieb Steinar H. Gunderson:
Well, it's logical enough; it scans along activity_id until it finds one
with state=1 or state=10001. You obviously have a _lot_ of records with
low activity_id and state none of these two, so Postgres needs to scan all
those
On Thu, Mar 30, 2006 at 02:59:02PM +0200, Peter Eisentraut wrote:
Well, it's logical enough; it scans along activity_id until it finds one
with state=1 or state=10001. You obviously have a _lot_ of records with
low activity_id and state none of these two, so Postgres needs to scan all
On Thu, Mar 30, 2006 at 02:51:47PM +0200, Steinar H. Gunderson wrote:
On Thu, Mar 30, 2006 at 07:42:53AM -0500, Michael Stone wrote:
Yes. And the estimates are bad enough (orders of magnitude) that I can't
help but wonder whether pg could come up with a better plan with better
statistics:
-
I have noticed that a lot of people have a hard
time finding out how to tune postgresql to suit their hardware.
Are there any tools for automatic tuning of the
parameters in postgresql.conf? A simple program
running some benchmarks on cpu disk speed, checking the amount of ram
and so on
Michael Stone [EMAIL PROTECTED] writes:
Yes. I was looking at the other side; I thought pg could estimate how
much work it would have to do to hit the limit, but double-checking it
looks like it can't.
Yes, it does, you just have to understand how to interpret the EXPLAIN
output. Peter had
I use Npgsql, and the connection string I use is real simple:
Server=192.168.0.36;Database=mydb;User Id=myuserid;Password=123456
Hope that helps,
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:pgsql-performance-
[EMAIL PROTECTED] On Behalf Of Greg Quinn
Sent: Wednesday,
Tom Lane wrote:
The problem here appears to be a non-random correlation between state
and activity, such that the desired state values are not randomly
scattered in the activity sequence. The planner doesn't know about
that correlation and hence can't predict the poor startup time.
So from
Gavin Hamill [EMAIL PROTECTED] writes:
The table has just under six million rows - should it really be taking
nearly six minutes to add an index?
Try running it with trace_sort enabled to get more info about where the
time is going.
We've been doing some considerable work on the sorting code
Peter Eisentraut [EMAIL PROTECTED] writes:
So from when to when is the startup time (the x in x..y) actually
measured? When does the clock start ticking and when does it stop?
That is what's confusing me.
The planner thinks of the startup time (the first estimated-cost number)
as the time
On Thu, 2006-03-30 at 09:26 +0100, Gavin Hamill wrote:
Hullo, I have pg 8.1.3 on an 8-CPU AIX 5.3 box with 16GB of RAM, and I'm
finding that it's taking an age to CREATE INDEX on a large table:
Column | Type |
Modifiers
[EMAIL PROTECTED] (Craig A. James) writes:
Gorshkov wrote:
/flame on
if you were *that* worried about performance, you wouldn't be using
PHP or *any* interperted language
/flame off
sorry - couldn't resist it :-)
I hope this was just a joke. You should be sure to clarify - there
might
On Thu, 2006-03-30 at 11:22, Chris Browne wrote:
[EMAIL PROTECTED] (Craig A. James) writes:
Gorshkov wrote:
/flame on
if you were *that* worried about performance, you wouldn't be using
PHP or *any* interperted language
/flame off
sorry - couldn't resist it :-)
I hope this was
Tom Lane wrote:
Gavin Hamill [EMAIL PROTECTED] writes:
The table has just under six million rows - should it really be taking
nearly six minutes to add an index?
Try running it with trace_sort enabled to get more info about where the
time is going.
We've been doing some considerable
And yes, it does become natural to ask why not write CGIs in ASM?
;-)
Personally, I'd code it in brainfuck, for aesthetic reasons.
And that, nowadays, is generally the state of web development. It's not
the language you're using to write it in, it's how efficiently you're
using
On Thu, Mar 30, 2006 at 11:31:25PM +0200, PFC wrote:
So, one wonders why some use 70's languages like Java instead of
Lisp or Python, which are slower, but a lot more powerful and faster
to
develop in...
(and don't have hibernate, which is a big bonus)
(why do
jython is a full rewrite of python in java and interface naturally with
java classes, therefore hibernate ... and is just as easy as python.
Steinar H. Gunderson a écrit :
On Thu, Mar 30, 2006 at 11:31:25PM +0200, PFC wrote:
So, one wonders why some use 70's languages like Java
On 30.03.2006, at 23:31 Uhr, PFC wrote:
(why do you think I don't like Java ?)
Because you haven't used a good framework/toolkit yet? Come on, the
language doesn't really matter these days, it's all about frameworks,
toolkits, libraries, interfaces and so on.
But, nevertheless,
27 matches
Mail list logo
