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 bu
2010/2/25 Tory M Blue :
> 2010/2/25 Devrim GÜNDÜZ :
>> 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 b
2010/2/25 Devrim GÜNDÜZ :
> 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
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
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 'checkpoint
On Thu, Feb 25, 2010 at 10:12 PM, Tory M Blue 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, no retrans,
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
Bruce Momjian 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 your subscription:
Did this get addressed?
---
Tom Lane wrote:
> Kris Jurka 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 output size.
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 R
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 http://w
Thanks for the reply.
On Thu, Feb 25, 2010 at 5:48 PM, Greg Smith 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 system and postg
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,
moder
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 me.
"Julien Theulier" 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 SQL-standard syntax
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, th
-- 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 go
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 return
18 matches
Mail list logo
