On Dec 23, 2005, at 5:15 PM, Mark Kirkwood wrote:
Vivek Khera wrote:
and only the opteron boxes needed to come from sun. add a zero
return policy and you wonder how they expect to keep in business
sorry, i had to vent.
Just out of interest - why did the opterons need to come from Su
YES it worked very nice Using UNION with 8.0.3: Append (cost=0.00..164840.70 rows=232632 width=892) (actual time=0.350..28529.895 rows=167711 loops=1) -> Subquery Scan "*SELECT* 1" (cost=0.00..2.91 rows=1 width=892) (actual time=0.098..0.098 rows=0 loops=1) -> Index S
Vivek Khera wrote:
and only the
opteron boxes needed to come from sun. add a zero return policy and you
wonder how they expect to keep in business
sorry, i had to vent.
Just out of interest - why did the opterons need to come from Sun?
---(end of broadcast
On Dec 22, 2005, at 11:14 PM, David Lang wrote:
but it boils down to the fact that there just isn't enough
experiance with the new sun systems to know how well they will
work. they could end up being fabulous speed demons, or dogs (and
it could even be both, depending on your workload)
T
On Dec 22, 2005, at 9:44 PM, Juan Casero wrote:
Agreed. I have a 13 million row table that gets a 100,000 new
records every
week. There are six indexes on this table. Right about the time
when it
i have some rather large tables that grow much faster than this (~1
million per day on
Carlos Benkendorf <[EMAIL PROTECTED]> writes:
> For some implementation reason in 8.0.3 the query is returning the rows in
> the correct order even without the order by but in 8.1.1 probably the
> implementation changed and the rows are not returning in the correct order.
It was pure luck that
Anton Maksimenkov <[EMAIL PROTECTED]> writes:
> Second idea was to try to SELECT (user, cookie) pair and then UPDATE
> it if it exists or INSERT if not. I has thought that if UPDATE will
> rewrite same place in file with new count it may lead to more compact
> table (file not grow and information
On 23.12.2005, at 15:35 Uhr, Carlos Benkendorf wrote:
I appreciate your suggestion but I think I´m misunderstanding
something, the select statement should return at about 150.000
rows, why 5 rows?
I have looked at the wrong lines of the explain ... statement. Sorry,
my fault. With that ma
Carlos Benkendorf wrote:
Hi,
We have more than 200 customers running 8.0.3 and two weeks ago
started migration project to 8.1.1.After the first migration to 8.1.1
we had to return back to 8.0.3 because some applications were not
working right.
Our user told me that records are not returni
>If you can't force PostgreSQL to perform better on the ordered query, >what about retrieving only the primary keys for the rows you want >unordered in a subquery and using an "where primaryKey in (...) order >by ..." statement with ordering the five rows? I appreciate your suggestion but I thi
On 23.12.2005, at 13:34 Uhr, Carlos Benkendorf wrote:
For some implementation reason in 8.0.3 the query is returning the
rows in the correct order even without the order by but in 8.1.1
probably the implementation changed and the rows are not returning
in the correct order.
You will never
We agree completely with you and that is what we are doing right now. But what I would like is really understand the reason for this behavior and be sure we can not do anything more to improve the runtimes. BenkendorfMario Weilguni <[EMAIL PROTECTED]> escreveu: I think whatever the reas
I think whatever the reasons for the different query plans are (and if that
can be fixed) - you CANNOT assume that data comes in sorted order when you do
not use order by. Thats what every database does this way. So, use order by,
or you'll be in trouble sooner or later.
Best regards,
M
Hi, We have more than 200 customers running 8.0.3 and two weeks ago started migration project to 8.1.1.After the first migration to 8.1.1 we had to return back to 8.0.3 because some applications were not working right. Our user told me that records are not returning more in the correct orde
Hi, all.
While working on algorithm of my project I came to question. Let it
be table like this (user+cookie pair is the primary key).
INT user
INT cookie
INT count
Periodically (with period 10 minutes) this PostgreSQL table
updated with my information.
The main problem that some of pairs (us
15 matches
Mail list logo
