On Wed, Mar 26, 2008 at 10:09 PM, Shane Ambler <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > On Wed, Mar 26, 2008 at 1:48 PM, p prince <[EMAIL PROTECTED]> wrote:
> >> is this 'normal'? (loaded question I know)
> >> Should I be looking to offload expensive reporting queries to read-only
>
Scott Marlowe wrote:
On Wed, Mar 26, 2008 at 1:48 PM, p prince <[EMAIL PROTECTED]> wrote:
is this 'normal'? (loaded question I know)
Should I be looking to offload expensive reporting queries to read-only
replicants of my database?
Yes, definitely look into setting up something like a slony sl
On Tue, Mar 25, 2008 at 3:35 AM, sathiya psql <[EMAIL PROTECTED]> wrote:
> Dear Friends,
> I have a table with 32 lakh record in it. Table size is nearly 700 MB,
> and my machine had a 1 GB + 256 MB RAM, i had created the table space in
> RAM, and then created this table in this RAM.
>
> S
is this 'normal'? (loaded question I know)
Depends. If you are on the edge, disk-wise, yes a big fat query can push
it over and make it fall.
Should I be looking to offload expensive reporting queries to read-only
replicants of my database?
You could do this, especially if the heavy q
On Wed, Mar 26, 2008 at 1:48 PM, p prince <[EMAIL PROTECTED]> wrote:
> is this 'normal'? (loaded question I know)
> Should I be looking to offload expensive reporting queries to read-only
> replicants of my database?
Yes, definitely look into setting up something like a slony slave
that's used for
On Wednesday 26 March 2008, "p prince" <[EMAIL PROTECTED]> wrote:
> Is this a sign of disk contention?
Yes.
> How does CPU load come into play?
Processes waiting for disk I/O generally show up as load.
--
Alan
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To m
On Wed, 26 Mar 2008 12:49:56 -0800
Vinubalaji Gopal <[EMAIL PROTECTED]> wrote:
> The big table has never been reindexed and has a primary, unique key
> with btree index and one foreign key constraint.
The slowness is likely attributed to Vacuum's use of I/O. When vacuum
is running what does iosta
Hey all,
I had posted sometime back asking for the best way to perform vacuum
with a lower priority - I did tune it up to a lower priority
and still noticed that the other database queries are slowing down
with a vacuum on one big table. I also tried to upgrade Postgresql to
8.0.15 as suggested
I'm not a DBAbut I play one at my office.
I also have a hand in system administration, development and stairwell
sweeping.
Small shop...many hats per person.
We have a postgresql (v8.2.X) database with about 75 gigabytes of
data.almost half of it is represented by audit tables (changes mad
Dear Sirs,
I am doing this project of optimizing pg-sql query engine with compressed
annealing. I would like to know if any deficiency in existing GEQO. If there
are any TODO items remaining in GEQO kindly brief about the same. Awaiting
discussions on this.
GN
--
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
You say you need faster INSERT performance. Getting rid of some indexes
is a way, but can you tell a bit more about your hardware setup ?
For instance, if you only have one HDD, put an extra HDD in
Marinos Yannikos wrote:
Which version do you have? Since 8.1 pg can use a so called 'bitmap
index scan', because of this feature i guess you don't need the index
foo3. (if you have 8.1 or higher)
8.3.1 - foo3 is being used though in presence of both foo1 and foo2,
so I'd suppose that it's a b
am Wed, dem 26.03.2008, um 16:15:20 +0100 mailte Marinos Yannikos folgendes:
> A. Kretschmer schrieb:
> >>create index foo1 on bla (a);
> >>create index foo2 on bla (b);
> >>create index foo3 on bla (a,b);
> >>[...]
> >
> >Which version do you have? Since 8.1 pg can use a so called 'bitmap
> >inde
A. Kretschmer schrieb:
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
[...]
Which version do you have? Since 8.1 pg can use a so called 'bitmap
index scan', because of this feature i guess you don't need the index
foo3. (if you have 8.1 or higher)
On Wed, 26 Mar 2008, A. Kretschmer wrote:
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
Which version do you have? Since 8.1 pg can use a so called 'bitmap
index scan', because of this feature i guess you don't need the index
foo3. (if you have 8.1
am Wed, dem 26.03.2008, um 15:18:53 +0100 mailte Marinos Yannikos folgendes:
> Hello,
>
> we have several indexes such as:
>
> create index foo1 on bla (a);
> create index foo2 on bla (b);
> create index foo3 on bla (a,b);
>
> They are all used often by frequently used queries (according to
>
Hello,
we have several indexes such as:
create index foo1 on bla (a);
create index foo2 on bla (b);
create index foo3 on bla (a,b);
They are all used often by frequently used queries (according to
pg_statio_user_indexes), but we need somewhat higher INSERT/UPDATE
performance (having tuned mos
th maximum number of records in one PostreSQL table ist unlimited:
am asking for good performance, not just limitation..
If i have half a crore record, how the performance will be ?
How long is a piece of string?
It depends what you are doing, whether you have indexes, how the tables
are ar
18 matches
Mail list logo
