Pailloncy Jean-Gerard <[EMAIL PROTECTED]> wrote ..
[snip]
THIS MAY SEEM SILLY but vacuum is mispelled below and presumably there was
never any ANALYZE done.
>
> postgres=# vaccum full verbose analyze;
---(end of broadcast)---
TIP 3: Have you che
Luke Lonergan wrote:
Mark,
This is an excellent idea – unfortunately I’m in Maui right now
(Mahalo!) and I’m not getting to testing with this. My first try was
with 8.0.3 and it’s an 8.1 function I presume.
Not to be lazy – but any hint as to how to do the same thing for 8.0?
Yeah, it's
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
> Why the stupid indexscan plan on the whole table ?
Pray tell, what are you using for the planner cost parameters?
The only way I can come close to duplicating your numbers is
by setting random_page_cost to somewhere around 0.01 ...
Title: Re: [PERFORM] Hardware/OS recommendations for large databases (
Mark,
This is an excellent idea – unfortunately I’m in Maui right now (Mahalo!) and I’m not getting to testing with this. My first try was with 8.0.3 and it’s an 8.1 function I presume.
Not to be lazy – but any hint as to
Alan,
On 11/23/05 2:00 PM, "Alan Stange" <[EMAIL PROTECTED]> wrote:
> Luke Lonergan wrote:
>> Why not contribute something - put up proof of your stated 8KB versus
>> 32KB page size improvement.
>
> I did observe that 32KB block sizes were a significant win "for our
> usage patterns". It might
Hi,
PostgreSQL 8.1 fresh install on a freshly installed OpenBSD 3.8 box.
postgres=# CREATE DATABASE test;
CREATE DATABASE
postgres=# create table test (id serial, val integer);
NOTICE: CREATE TABLE will create implicit sequence "test_id_seq" for
serial column "test.id"
CREATE TABLE
postgres=
Luke Lonergan wrote:
Why not contribute something - put up proof of your stated 8KB versus
32KB page size improvement.
I did observe that 32KB block sizes were a significant win "for our
usage patterns". It might be a win for any of the following reasons:
0) The preliminaries: ~300GB dat
Simon,
I tested it by running two of those simultaneous queries (the
'unoptimized' one), and it doesn't make any difference whether
vm.max-readahead is 256 or 2048...the modified query runs in a snap.
Thanks,
Anjan
-Original Message-
From: Anjan Dave
Sent: Wednesday, November 23, 2005 1
The offending SELECT query that invoked the CS storm was optimized by
folks here last night, so it's hard to say if the VM setting made a
difference. I'll give it a try anyway.
Thanks,
Anjan
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005
On Tue, 2005-11-22 at 18:17 -0500, Anjan Dave wrote:
> It's mostly a 'read' application, I increased the vm.max-readahead to
> 2048 from the default 256, after which I've not seen the CS storm,
> though it could be incidental.
Can you verify this, please?
Turn it back down again, try the test, t
Title: Re: [PERFORM] Hardware/OS recommendations for large databases (
Alan,
Why not contribute something - put up proof of your stated 8KB versus 32KB page size improvement.
- Luke
Bruce,
On 11/22/05 4:13 PM, "Bruce Momjian" wrote:
> Perfect summary. We have a background writer now. Ideally we would
> have a background reader, that reads-ahead blocks into the buffer cache.
> The problem is that while there is a relatively long time between a
> buffer being dirtied and th
12 matches
Mail list logo
