On Fri, May 13, 2011 at 09:09:41PM +, John Rouillard wrote:
> Hi all:
>
> I am adding pgiosim to our testing for new database hardware and I am
> seeing something I don't quite get and I think it's because I am using
> pgiosim incorrectly.
>
> Specs:
>
> OS: centos 5.5 kernel: 2.6.18-194.3
Hi Lars,
I do not know if this makes sense in PostgreSQL and that readers
do not block writers and writes do not block readers. Are your
UPDATEs to individual rows, each in a separate transaction, or
do you UPDATE multiple rows in the same transaction? If you
perform multiple updates in a single t
On Mon, Jul 11, 2011 at 05:26:49PM +0200, Robert Klemme wrote:
> On Mon, Jul 11, 2011 at 3:13 PM, k...@rice.edu wrote:
> > I do not know if this makes sense in PostgreSQL and that readers
> > do not block writers and writes do not block readers. Are your
> > UPDATEs to indiv
On Mon, Jul 18, 2011 at 01:48:20PM -0600, M. D. wrote:
> I have 2 small servers, one a fairly new server with a x3450 (4-core
> with HT) cpu running at 2.67GHz and an older E5335 (4-core) cpu
> running at 2GHz.
>
> I have been quite surprised how the E5335 compares very closely to
> the x3450, but
On Mon, Jul 18, 2011 at 11:56:40PM +0200, Tomas Vondra wrote:
> Dne 18.7.2011 22:11, k...@rice.edu napsal(a):
> >> > In my testing I have a 32bit CentOS on the x3450, but a 64bit CentOS
> >> > on the E5335. Can this make such a bit difference or should the
> >>
On Thu, Aug 11, 2011 at 04:35:34PM -0700, Waldo Nell wrote:
> I have PostgreSQL 8.4.8 on Ubuntu Linux x64. Server is a Core i7 950 with
> 6GB of RAM. 2GB of RAM us used by Java, some small amount by the kernel /
> services and the rest is available to PostgreSQL. Hard drive is a single
> 7200
On Wed, Aug 17, 2011 at 10:59:12AM -0700, bobbyw wrote:
> Awesome.. that did it! It was actually not set at all in postgresql.conf,
> although it was commented out as:
>
> # unix_socket_directory = ''
>
> Presumably it was using the default of '/tmp'?
>
> Anyway, after making that change dbt5
On Wed, Aug 17, 2011 at 01:26:56PM -0500, Ogden wrote:
> I am using bonnie++ to benchmark our current Postgres system (on RAID 5) with
> the new one we have, which I have configured with RAID 10. The drives are the
> same (SAS 15K). I tried the new system with ext3 and then XFS but the results
>
On Wed, Aug 17, 2011 at 01:32:41PM -0500, Ogden wrote:
>
> On Aug 17, 2011, at 1:31 PM, k...@rice.edu wrote:
>
> > On Wed, Aug 17, 2011 at 01:26:56PM -0500, Ogden wrote:
> >> I am using bonnie++ to benchmark our current Postgres system (on RAID 5)
> >> with
On Wed, Aug 17, 2011 at 03:40:03PM -0500, Ogden wrote:
>
> On Aug 17, 2011, at 1:35 PM, k...@rice.edu wrote:
>
> > On Wed, Aug 17, 2011 at 01:32:41PM -0500, Ogden wrote:
> >>
> >> On Aug 17, 2011, at 1:31 PM, k...@rice.edu wrote:
> >>
> >>>
On Wed, Sep 14, 2011 at 03:40:07PM -0400, Igor Neyman wrote:
>
>
> From: Carlo Stonebanks [mailto:stonec.regis...@sympatico.ca]
> Sent: Tuesday, September 13, 2011 9:27 PM
> To: Performance support Postgresql
> Subject: Re: Migrated from 8.3 to 9.0 - need to update config (re-post)
>
>
>
> _
On Wed, Sep 21, 2011 at 11:22:53PM -0400, Tom Lane wrote:
> Michael Viscuso writes:
> > Greg/Tom, you are correct, these columns should be modified to whatever
> > is easiest for Postgres to recognize 64-bit unsigned integers. Would
> > you still recommend bigint for unsigned integers? I likely
On Tue, Nov 01, 2011 at 08:33:51AM +0530, Mohamed Hashim wrote:
> Any idea or suggestions how to improve my database best
> performance.???
>
> Regards
> Hashim
>
Hi Hashim,
Ignoring the description of your tables, you should probably try
updating to the latest release 9.0.5. You
On Thu, Nov 03, 2011 at 03:48:11PM +0100, Albe Laurenz wrote:
>
> I experimented some more on a recent system (RHEL6, OpenSSL 1.0.0-fips),
> and it is as you say. Disabling OpenSSL compression in the source (which
> is possible since OpenSSL 1.0.0) does not give me any performance
> improvement.
>
On Mon, Nov 07, 2011 at 08:36:10AM -0200, Lucas Mocellin wrote:
> Hi everybody,
>
> I'm having some issues with PostgreSQL 9.03 running on FreeBSD 8.2 on top
> of VMware ESXi 4.1 U1.
>
> The problem is query are taking too long, and some times one query "blocks"
> everybody else to use the DB as
Wow, upgrading 3 major releases at a go. :) It would probably be
useful to use the helpful:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
to get the information that is needed to the right people.
Regards,
Ken
On Mon, Dec 19, 2011 at 04:04:54PM +0100, Rafael Martinez wrote:
>
On Thu, Feb 23, 2012 at 05:25:46PM +0200, Reuven M. Lerner wrote:
> >
> >What is the distribution of end_dates? It might be worth running this in
> >several steps, deleting records older than, say, 90 days, 60 days, 30 days.
>
> I've suggested something similar, but was told that we have limited
>
Hi Rafael,
Try disabling the prepare statement processing in DBD::Pg and
try the timing runs again.
Regards,
Ken
On Wed, Mar 21, 2012 at 12:21:23PM +0100, Rafael Martinez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello
>
> We are having some performance problems with an appl
On Fri, Mar 30, 2012 at 02:45:36PM +, Campbell, Lance wrote:
> PostgreSQL 9.0.x
> When PostgreSQL storage is using a relatively large raid 5 or 6 array is
> there any value in having your tables distributed across multiple tablespaces
> if those tablespaces will exists on the same raid arra
On Wed, Jul 11, 2012 at 10:05:48AM -0400, Tom Lane wrote:
> Daniel Farina writes:
> > TRUNCATE should simply be very nearly the fastest way to remove data
> > from a table while retaining its type information, and if that means
> > doing DELETE without triggers when the table is small, then it sho
On Tue, Aug 14, 2012 at 10:10:47AM -0700, Jeff Janes wrote:
> On Tue, Aug 14, 2012 at 8:27 AM, Doug Hunley wrote:
> > According to the docs on cluster:
> > if you tend to access some data more than others, and there is an
> > index that groups them together, you will benefit from using CLUSTER
> >
On Thu, Sep 27, 2012 at 03:50:33PM -0500, Shaun Thomas wrote:
> On 09/27/2012 03:44 PM, Scott Marlowe wrote:
>
> >This 100x this. We used to buy our boxes from aberdeeninc.com and got
> >a 5 year replacement parts warranty included. We spent ~$10k on a
> >server that was right around $18k from d
On Tue, Oct 16, 2012 at 01:26:37PM +0100, Alejandro Carrillo wrote:
> Hi,
>
> Why PostgreSQL, the EnterpriseBD supports create/alter/drop package and the
> opensource doesn't?
> Is a project or never will have support?
>
Hi Alejandro,
Isn't that part of their Oracle compatibility secret sauce?
On Fri, Oct 26, 2012 at 04:37:33PM +0200, Böckler Andreas wrote:
> Hi,
>
>
> Am 25.10.2012 um 20:22 schrieb Kevin Grittner:
>
> >
> > The idea is to model actual costs on your system. You don't show
> > your configuration or describe your hardware, but you show an
> > estimate of retrieving ov
On Fri, Oct 26, 2012 at 05:15:05PM +0200, Böckler Andreas wrote:
> Hi Ken,
>
> Am 26.10.2012 um 16:55 schrieb k...@rice.edu:
>
> > Hi Andy,
> >
> > You have the sequential_page_cost = 1 which is better than or equal to
> > the random_page_cost in all of y
On Mon, Oct 29, 2012 at 02:05:24PM +0100, Albe Laurenz wrote:
> I am configuring streaming replication with hot standby
> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
> PostgreSQL was compiled from source.
>
> It works fine, except that starting the standby took for ever:
> it t
On Tue, Oct 30, 2012 at 09:50:44AM +0100, Albe Laurenz wrote:
> >> On Mon, Oct 29, 2012 at 6:05 AM, Albe Laurenz
> wrote:
> >>> I am configuring streaming replication with hot standby
> >>> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
> >>> PostgreSQL was compiled from source.
>
On Tue, Oct 30, 2012 at 02:16:57PM +0100, Albe Laurenz wrote:
> k...@rice.edu wrote:
> >>> If you do not have good random io performance log replay is nearly
> >>> unbearable.
> >>>
> >>> also, what io scheduler are you using? if it is cfq change
Hi Rodrigo,
It looks like a lot of joins and 9.2 does some optimizations that
internally add additional joins. Did you try raising the
join_collapse_limit and maybe the from_collapse_limit from the
default values of 8?
Regards,
Ken
On Tue, Nov 06, 2012 at 03:11:58PM -0200, Rodrigo Rosenfeld Rosa
Hi Patrick,
You really need a flash ZIL with ZFS to handle syncs effectively. Setting
the sync_commit to off is the best you can do without it. Not that that
is bad, we do that here as well.
Regards,
Ken
On Tue, Jan 08, 2013 at 01:18:02AM +0800, Patrick Dung wrote:
> Hi,
>
> Updated information
On Sun, Jan 27, 2013 at 03:15:45AM +0300, belal hamed wrote:
>
> I connect to my server through ADSL connection 4Mbps
>
Here is your "problem". You need to understand the performance
characteristics of your communication channel. ADSL is a VERY
asymmetric communications channel. Down is usually
On Sun, Jan 27, 2013 at 03:09:55PM +0300, belal hamed wrote:
> >Here is your "problem". You need to understand the performance
> >characteristics of your communication channel. ADSL is a VERY
> >asymmetric communications channel. Down is usually much faster
> >than up.
>
> How it could be ADSL pro
On Thu, Mar 28, 2013 at 02:03:42PM -0700, Kevin Grittner wrote:
> kelphet xiong wrote:
>
> > When I use postgres and issue a simple sequential scan for a
> > table inventory using query "select * from inventory;", I can see
> > from "top" that postmaster is using 100% CPU, which limits the
> > qu
On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
> I'm encountering an issue where PG 9.2.4 (we also see this with
> 9.2.3) is picking a plan involving a bitmap heap scan that turns out
> to be much slower than a nested-loop plan using indexes.
>
> The planner picks the hashjoin plan
On Wed, Apr 10, 2013 at 11:56:32AM -0400, Steve Singer wrote:
> On 13-04-10 09:56 AM, k...@rice.edu wrote:
> >On Wed, Apr 10, 2013 at 09:49:55AM -0400, Steve Singer wrote:
>
> >
> >Hi Steve,
> >
> >The one thing that stands out to me is that you are working wit
On Thu, Apr 11, 2013 at 04:30:54PM -0700, bing1221 wrote:
> Our server is running postgresql 8.4.15. During day time the cpu usage always
> around 80%, but it's not IO bound. The swap space is looking OK also. Also
> we setup pgbadger and enable all logs to monitor the slow query but they all
> fin
On Wed, May 01, 2013 at 02:05:06PM +, Anne Rosset wrote:
> Hi all,
> We are running a stress test that executes one select query with multiple
> threads.
> The query executes very fast (10ms). It returns 100 rows. I see
> deterioration in the performance when we have multiple threads executi
On Wed, May 01, 2013 at 04:07:55PM +, Anne Rosset wrote:
> Hi Ken,
> Thanks for your answer. My test is actually running with jboss 7/jdbc and the
> connection pool is defined with min-pool-size =10 and max-pool-size=400.
>
> Why would you think it is an issue with the connection pool?
>
>
On Tue, May 14, 2013 at 11:52:29PM -0700, Christoph Berg wrote:
> Re: Mark Felder 2013-05-13
> > What version of DBIx-SearchBuilder do you have on that server? The
> > RT guys usually recommend you have the latest possible so RT is
> > performing the most sane/optimized queries possible for your
>
On Tue, May 21, 2013 at 05:28:31PM +0400, Evgeny Shishkin wrote:
>
> On May 21, 2013, at 5:18 PM, Jeison Bedoya wrote:
>
> > Hi people, i have a database with 400GB running in a server with 128Gb RAM,
> > and 32 cores, and storage over SAN with fiberchannel, the problem is when i
> > go to do
On Wed, Jun 26, 2013 at 10:36:10PM +0200, Willy-Bas Loos wrote:
> On Wed, Jun 26, 2013 at 10:31 PM, Jeff Janes wrote:
>
> >
> > Why is it retrieving 3.1 million, when it only needs 17?
> >
> >
> > that's because of the sequential scan, it reads all the data.
>
> cheers,
>
> willy-bas
Well, the
On Tue, Sep 10, 2013 at 11:04:21AM -0400, David Whittaker wrote:
> Hi All,
>
> I've been seeing a strange issue with our Postgres install for about a year
> now, and I was hoping someone might be able to help point me at the cause.
> At what seem like fairly random intervals Postgres will become u
On Thu, Oct 03, 2013 at 04:19:29AM +, Samuel Stearns wrote:
> Thanks, Claudio.
>
> I'll have a look at the clustering.
>
> We have also noticed that the same query with a datetime range of 3 hours
> (rather than 4 months) runs in just 30 seconds:
>
> AND datetime <= '2013-10-03 10:03:49'
>
On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote:
> On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка
> wrote:
> > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections
> > from components wich use jdbc. I don't think that this is a good idea use
> > pgbouncer, be
On Mon, Nov 18, 2013 at 02:38:09PM -0200, Rogerio Pereira wrote:
> Hi,
>
> I am need help, about subject "Query cache in Postgres".
> how is it possible to put sql statements cached in postgres ?
> I did some tests and I can not get even with improved tuning
> parameters in the postgresql.conf.
>
On Mon, Nov 18, 2013 at 04:36:20PM -0800, salah jubeh wrote:
> Hello,
>
> pgpool supports memcache.
> Regards
>
Very cool. I had missed that in the release announcement.
Regards,
Ken
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscrip
On Fri, Apr 04, 2014 at 10:26:22PM +0200, PARIS Nicolas wrote:
> this postgres documentation :
> http://www.postgresql.org/docs/9.3/static/ecpg-connect.html
> says it is actually possible to manage connection in C stored procedure.
>
> I may be wrong...
>
>
> Le 04/04/2014 22:14, Thom Brown a éc
On Fri, Oct 03, 2014 at 10:55:04AM +0200, Roberto Grandi wrote:
> Dear Pg people,
>
> I would ask for your help considering this scaling issue. We are planning to
> move from 3Millions of events/day instance of postgres (8 CPU, 65 gb ram) to
> 5 millions of items/day.
> What do you suggest in or
On Fri, Dec 05, 2014 at 09:42:20AM +1300, Michael Barker wrote:
> 1) Created table with hstore column and btree index.
>
> barkerm=# \d audit
>Table "public.audit"
> Column |Type |
> Modifiers
> ---+--
On Thu, Feb 12, 2015 at 11:25:54PM +0100, Nico Sabbi wrote:
> Hello,
> I've been away from postgres for several years, so please forgive
> me if I forgot nearly everything:-)
>
> I've just inherited a database collecting environmental data.
> There's a background process continually inserting rec
On Wed, Apr 29, 2015 at 07:07:04AM -0700, Joshua D. Drake wrote:
>
> On 04/29/2015 01:08 AM, Andres Freund wrote:
>
> >>Which OS and filesystem is this done on? Because many halfway modern
> >>systems, like e.g ext4 and xfs, implement this in the background as
> >>'delayed allocation'.
> >
> >Oh,
On Fri, Jun 12, 2015 at 09:37:36PM +, Sheena, Prabhjot wrote:
> Here is some more information
>
> pool_mode | transaction
>
> We have transactional pooling and our application is set up in such a way
> that we have one query per transaction. We have set default pool size to
On Thu, Jun 18, 2015 at 05:09:10PM +, Sheena, Prabhjot wrote:
> Guys
> I have an issue going on with PGBOUNCER which is slowing down the
> site
>
> PGBOUNCER VERSION: pgbouncer-1.5.4-2.el6 (Hosted on separate machine) (16
> cpu) 98GB RAM
> DATABASE VERION: postgresql 9.3
>
On Thu, Jun 18, 2015 at 05:41:01PM +, Sheena, Prabhjot wrote:
> Here is the output of OS limits
>
> postgres@symds-pg:~ $ ulimit -a
>
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (b
On Thu, Jun 18, 2015 at 07:19:13PM +, Sheena, Prabhjot wrote:
> Hi Ken/ Will
>
> I have checked the ulimit value and we are nowhere hitting the max 4096
> that we have currently set. Is there any other explanation why we should be
> thinking of bumping it to like ulimit -n 5000
On Thu, Sep 17, 2015 at 03:14:43PM -0400, Dave Stibrany wrote:
> Hi all. I am occasionally seeing really slow update/inserts into a fairly
> large table. By really slow I mean around 10-40 seconds,
> while the majority of queries take milliseconds. I cannot reproduce this
> problem myself, but it i
On Tue, Sep 29, 2015 at 05:45:41PM +0200, Bertrand Paquet wrote:
> Hi,
>
> We have got big slow down on our production plateform (PG 9.4.4).
> After analyzing wals with pg_xlogdump, we see lot of writing in Gin Indexes.
> We suspect slow down are related to the write of pending update on the
> ind
On Thu, Oct 08, 2015 at 11:08:55AM -0400, Carlo wrote:
> >> Sounds like a locking problem
>
> This is what I am trying to get at. The reason that I am not addressing
> hardware or OS configuration concerns is that this is not my environment,
> but my client's. The client is running my import softw
On Thu, Oct 08, 2015 at 05:43:11PM -0400, Carlo wrote:
> -Original Message-
> From: k...@rice.edu [mailto:k...@rice.edu]
> Sent: October 8, 2015 1:00 PM
> To: Carlo
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] One long transaction or multiple short tra
On Thu, Mar 31, 2016 at 02:56:48PM -0400, Tom Lane wrote:
> Chris Cogdon writes:
> > Hi folks! I’ve a query where adding a rollup to the group by switches to
> > GroupAggregate unexpectedly, where the standard GROUP BY uses
> > HashAggregate.
>
> The current implementation of rollup doesn't suppo
On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote:
> Hi,
>
> I have an application which stores a large amounts of hex-encoded hash
> strings (nearly 100 GB of them), which means:
>
>- The number of distinct characters (alphabet) is limited to 16
>- Each string is of the same len
On Wed, Jun 15, 2016 at 03:09:04PM +0200, Ivan Voras wrote:
> On 15 June 2016 at 15:03, k...@rice.edu wrote:
>
> > On Wed, Jun 15, 2016 at 11:34:18AM +0200, Ivan Voras wrote:
> > > Hi,
> > >
> > > I have an application which stores a large amounts of hex-en
On Wed, Jun 15, 2016 at 04:20:46PM +0200, Ivan Voras wrote:
> Hi,
>
> Just for testing... is there a fast (i.e. written in C) crc32 or a similar
> small hash function for PostgreSQL?
>
Hi Ivan,
Here is an extension that provides a number of different hash
functions, including a version of the v
63 matches
Mail list logo
