On 24/02/10 23:37, Dave Crooke wrote:
1. The city temps table is a toy example, not meant to be realistic :-)
You knew that and I guessed it, but it's worth stating these things for
people who read the archives a year from now.
2. Yes, my (Java) algorithm is deterministic ... it will
-- More explicit
select aggregate_using(max(date), city, temp, date) from bar group by
city, temp order by city;
select city, max(ROW(temp, date)) from bar group by city;
Does not work (alas) for lack of a default comparison for record type.
Another solution, which works wonders if you've
Hi all,
Just for your information, and this is not related to PG directly:
Teradata provides a qualify syntax which works as a filtering condition on
a windowed function result. This is the only DB allowing this direct
filtering on windowed functions, from what I know.
So, as an example,
Julien Theulier jul...@squidsolutions.com writes:
Teradata provides a qualify syntax which works as a filtering condition on
a windowed function result. This is the only DB allowing this direct
filtering on windowed functions, from what I know.
Seems like you could easily translate that into
Hi,
I have a couple of questions about dbt2 performance.
1. I tested dbt2+postgresql 8.4.2 on my server, but the NOTPM is around only
320~390 with 10 connections and 30 warehouses. Increasing the number of
connections did not improve the throughput? The NOPTM number does not seem
very high to
Yu-Ju Hong wrote:
2. Moreover, the disk utilization was high and the await time from
iostat is around 500 ms. Could disk I/O limit the overall throughput?
The server has 2 SATA disks, one for system and postgresql and the
other is dedicated to logging (pg_xlog). As far as I understand,
modern
Thanks for the reply.
On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith g...@2ndquadrant.com wrote:
Yu-Ju Hong wrote:
2. Moreover, the disk utilization was high and the await time from
iostat is around 500 ms. Could disk I/O limit the overall throughput? The
server has 2 SATA disks, one for
Was there every any conclusion on this issue?
---
Matthew Wakeling wrote:
Revisiting the thread a month back or so, I'm still investigating
performance problems with GiST indexes in Postgres.
Looking at
Was this corrected? I don't see any commits to seg.c.
---
Matthew Wakeling wrote:
On Thu, 7 May 2009, Oleg Bartunov wrote:
Did you try Guttman quadratic split algorithm ? We also found linear
split algorithm for
Did this get addressed?
---
Tom Lane wrote:
Kris Jurka bo...@ejurka.com writes:
The real problem is getting reasonable stats to pass through the partition
Append step, so it can make a reasonable estimate of the join
Bruce Momjian br...@momjian.us writes:
Did this get addressed?
Partially. There are stats now but autovacuum is not bright about
when to update them.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
Okay ladies and gents and the rest of you :)
It's time I dig into another issue, and that's a curious 5 second
delay on connect, on occasion. Now, I believe the network to be sound
and there are zero errors on any servers, no retrans, no runts, nada
nada nada. However I will continue to run tests
On Thu, Feb 25, 2010 at 10:12 PM, Tory M Blue tmb...@gmail.com wrote:
Okay ladies and gents and the rest of you :)
It's time I dig into another issue, and that's a curious 5 second
delay on connect, on occasion. Now, I believe the network to be sound
and there are zero errors on any servers,
Friday, February 26, 2010, 7:20:38 AM you wrote:
checkpoint_completion_target (floating point)
interesting that it's a .5 second default setting and I'm seeing
exactly that .5 second delay.
It's not an exact time, but a multiplier to
On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote:
shared_buffers = 1500MB
Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit),
if needed. Please note that more shared_buffers will lead to more
pressure on bgwriter, but it also has lots of benefits, too.
work_mem = 100MB
2010/2/25 Devrim GÜNDÜZ dev...@gunduz.org:
On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote:
shared_buffers = 1500MB
Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit),
if needed. Please note that more shared_buffers will lead to more
pressure on bgwriter, but it also
2010/2/25 Tory M Blue tmb...@gmail.com:
2010/2/25 Devrim GÜNDÜZ dev...@gunduz.org:
On Thu, 2010-02-25 at 22:12 -0800, Tory M Blue wrote:
shared_buffers = 1500MB
Some people tend to increase this to 2.2GB(32-bit) or 4-6 GB (64 bit),
if needed. Please note that more shared_buffers will lead to
On Thu, 2010-02-25 at 23:01 -0800, Tory M Blue wrote:
Checkpoint_timeout is the default and that looks like 5 mins (300
seconds). And is obviously why I have such a discrepancy between time
reached and requested.
If you have a high load, you may want to start tuning with 15 minutes,
and bump
18 matches
Mail list logo