On Mon, Jan 30, 2012 at 17:35, Alessandro Gagliardi wrote:
> Well that was a *lot* faster:
>
> "HashAggregate (cost=156301.82..156301.83 rows=2 width=26) (actual
> time=2692.806..2692.807 rows=2 loops=1)"
> " -> Bitmap Heap Scan on blocks (cost=14810.54..155828.95 rows=472871
> width=26) (actu
pgwatch might also be worth taking a look at:
http://www.cybertec.at/en/postgresql_products/pgwatch-cybertec-enterprise-postgresql-monitor
Fernando.-
On Fri, Sep 30, 2011 at 18:29, Bobby Dewitt wrote:
> EnterpriseDB now has Postgres Enterprise Manager
> (
> http://enterprisedb.com/products-serv
On Sat, Jan 15, 2011 at 14:56, Barbara Woolums wrote:
> Hi there,
>
> Could someone please tell me why the following query won't work
>
> select DISTINCT get_unit(unit) as unit, get_ingredient(ing) as ing,
> get_ing_aisle(1,ing) as aisle
> from recipe_ing where recipe in(1084, 1086, 1012, 618) an
On Fri, Dec 17, 2010 at 07:48, selvi88 wrote:
>
> My requirement is more than 15 thousand queries will run,
> It will be 5000 updates and 5000 insert and rest will be select.
>
>
What IO system are you running Postgres on? With that kind of writes you
should be really focusing on your storage sol
> -Mensaje original-
> De: 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_buff
> -Mensaje original-
> De: Pierre Frédéric Caillaud
> Enviado el: Viernes, 15 de Enero de 2010 15:00
> Para: pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] new server I/O setup
>
>
> No-one has mentioned SSDs yet ?...
>
The post is about an already purchased server ju
> -Mensaje original-
> De: Matthew Wakeling [mailto:matt...@flymine.org]
> Enviado el: Viernes, 15 de Enero de 2010 08:21
> Para: Scott Marlowe
> CC: Fernando Hevia; pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] new server I/O setup
>
> On Thu, 14
> -Mensaje original-
> De: Greg Smith
>
>> Fernando Hevia wrote:
>>
>> I justified my first choice in that WAL writes are
>> sequentially and OS pretty much are too, so a RAID 1 probably
>> would hold ground against a 12 disc RAID 10 w
> -Mensaje original-
> De: Scott Marlowe
>
> I think your first choice is right. I use the same basic
> setup with 147G 15k5 SAS seagate drives and the pg_xlog / OS
> partition is almost never close to the same level of
> utilization, according to iostat, as the main 12 disk RAID-1
> -Mensaje original-
> De: fka...@googlemail.com
> Nevertheless: If your explanation covers all what can be said
> about it then replacing the hard disk by a faster one should
> increase the performance here (I'll try to check that out).
>
Moving the pg_xlog directory to the OS driv
Hi all,
I've just received this new server:
1 x XEON 5520 Quad Core w/ HT
8 GB RAM 1066 MHz
16 x SATA II Seagate Barracuda 7200.12
3ware 9650SE w/ 256MB BBU
It will run an Ubuntu 8.04 LTS Postgres 8.4 dedicated server. Its database
will be getting between 100 and 1000 inserts per second (those
> -Mensaje original-
> De: Keresztury Balázs
>
> hi,
>
> just a small question: is it normal that PostgreSQL 8.4.1
> always uses sequential scanning on any table when there is a
> condition having the constant "current_user"? Of course there
> is a btree index set on that table, but
> -Mensaje original-
> De: Waldomiro
>
> I´m using PostgreSQL 8.1,
Sorry, log_checkpoints isn't supported till 8.3
> and my settings are:
>
> checkpoint_segments=50
> checkpoint_timeout=300
> checkpoint_warning=30
> commit_delay=0
> commit_siblings=5
> archive_command= cp -i %p/BACK
> -Mensaje original-
> De: pgsql-performance-ow...@postgresql.org
> [mailto:pgsql-performance-ow...@postgresql.org] En nombre de Waldomiro
> Enviado el: Lunes, 30 de Noviembre de 2009 22:03
> Para: pgsql-performance@postgresql.org
> Asunto: [PERFORM] Server Freezing
>
> Hi everybody,
>
> -Mensaje original-
> De: Richard Neill
>
> Fernando Hevia wrote:
> >
> >
> >> -Mensaje original-
> >> De: Richard Neill
> >>
> >>
> >> max_connections = 500 # (change requires res
> -Mensaje original-
> De: Richard Neill
>
>
> max_connections = 500 # (change requires restart)
> work_mem = 256MB# min 64kB
Not that it has to do with your current problem but this combination could
bog your server if enough clients
> -Mensaje original-
> Laszlo Nagy
>
> My question is about the last option. Are there any good RAID
> cards that are optimized (or can be optimized) for SSD
> drives? Do any of you have experience in using many cheaper
> SSD drives? Is it a bad idea?
>
> Thank you,
>
>Laszlo
>
> -Mensaje original-
> De: mange
>
> Hi,
> I have a pretty small database on my home computer (~25Gb). I
> have three 250Gb HDDs.
>
> My setup was 1 HDD for OS (Windows XP) and the other 2 HDD
> in RAID 0 for postgre database.
> Will I see any performance improvement if I instead h
>>>
>>> User Access
>>> Total Number of Users is 500
>>> Maximum number of Concurrent users will be 500 during peak time
>>> Off Peak time the maximum number of concurrent user will be
>>> around 150 to 200.
>>>
>>
>>A connection pooler like pgpool or pgbouncer would considerably reduce the
>>burde
> -Mensaje original-
> De: Shiva Raman
> Enviado el: Martes, 22 de Septiembre de 2009 10:55
> Para: pgsql-performance@postgresql.org
> Asunto: [PERFORM] High CPU load on Postgres Server during
> Peak times
>
> Dear all
>
> I am having a problem of high cpu loads in my postgres
> -Mensaje original-
> De: Karl Denninger
> Enviado el: Sábado, 05 de Septiembre de 2009 21:19
> Para: Alvaro Herrera
> CC: Tom Lane; Merlin Moncure; Josh Berkus;
> pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] Planner question - "bit" data types
>
> There was a previous thr
> -Mensaje original-
> De: Paolo Rizzi
>
> Hi all,
> recently I came across a question from a customer of mine,
> asking me if it would feasible to run PostgreSQL along with
> PostGIS on embedded hardware.
> They didn't give me complete information, but it should be
> some kind of in
Incrementing shared_buffers to 1024MB and set effective_cache_size to 6000MB
and test again.
To speed up sort operations, increase work_mem till you notice an
improvement.
Play with those settings with different values.
_
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] En nombre de - -
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de cluster
> Enviado el: Sábado, 30 de Agosto de 2008 07:21
> Para: pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] Best hardware/cost tradoff?
>
> We are now leaning towards just buying 4 SAS d
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de cluster
>
> I'm about to buy a combined web- and database server. When
> (if) the site gets sufficiently popular, we will split the
> database out to a separate server.
>
> Our budget is limited, s
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
> "Bill Moran" <[EMAIL PROTECTED]> writes:
>
> > "Fernando Hevia" <[EMAIL PROTECTED]> wrote:
> >> Hi list.
> >> I have a table with over 30 million rows. Performance was dropp
Hi list.
I have a table with over 30 million rows. Performance was dropping steadily
so I moved old data not needed online to an historic table. Now the table
has about 14 million rows. I don't need the disk space returned to the OS
but I do need to improve performance. Will a plain vacuum do or
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de dforums
> Enviado el: Lunes, 11 de Agosto de 2008 11:27
> Para: Scott Marlowe; pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] Distant mirroring
>
> Houlala
>
> I got headache !!!
>
> So plea
> David Lang Wrote:
>
> with only four drives the space difference between raid 1+0 and raid 5
> isn't that much, but when you do a write you must write to two drives (the
> drive holding the data you are changing, and the drive that holds the
> parity data for that stripe, possibly needing to r
Mark Mielke Wrote:
>In my experience, software RAID 5 is horrible. Write performance can
>decrease below the speed of one disk on its own, and read performance will
>not be significantly more than RAID 1+0 as the number of stripes has only
>increased from 2 to 3, and if reading while writing, you
> Bill Moran wrote:
>
> RAID 10.
>
> I snipped the rest of your message because none of it matters. Never use
> RAID 5 on a database system. Ever. There is absolutely NO reason to
> every put yourself through that much suffering. If you hate yourself
> that much just commit suicide, it's les
Hi list,
I am building kind of a poor man's database server:
Pentium D 945 (2 x 3 Ghz cores)
4 GB RAM
4 x 160 GB SATA II 7200 rpm (Intel server motherboard has only 4 SATA ports)
Database will be about 30 GB in size initially and growing 10 GB per year.
Data is inserted overnight in two big tab
32 matches
Mail list logo
