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, t
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 i
[EMAIL PROTECTED] (Scott Marlowe) writes:
> 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 your database.
Which properly puts my comments in their place :-).
More importantly, that seems like
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
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 yo
On Thu, 30 Mar 2006 18:08:44 +0100
Simon Riggs <[EMAIL PROTECTED]> wrote:
Hello again Simon :)
> The index build time varies according to the number and type of the
> datatypes, as well as the distribution of values in the table. As well
> as the number of rows in the table.
>
> Note the x10 fac
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 considerabl
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 :-)
>
[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 -
On Thu, 2006-03-30 at 13:59 +0200, Peter Eisentraut wrote:
> Can anyone explain this:
>
> 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.05
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
>
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 t
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 co
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 fro
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,
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
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
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:
->
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
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
> th
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:
>
> -> Index Scan using activity_pk on activity (cost=0.00..407
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 tho
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 conditiona
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 row
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
http://de
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..6
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?
http://www.po
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 l
[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;
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 co
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
++---
31 matches
Mail list logo
