Hello,
When I run an SQL to create new tables and indexes is when Postgres consumes
all CPU and impacts other users on the server.
We are running Postgres 8.3.7 on a Sun M5000 with 2 x quad core CPUs (16
threads) running Solaris 10.
I've attached the sar data at the time of the run- here's a s
On 6/30/2010 2:21 PM, Jignesh Shah wrote:
If the underlying WAL disk is SSD then it seems I can get
synchronous_commit=on to work faster than
synchronous_commit=off..
The first explanation that pops to mind is that synchronous_commit is
writing all the time, which doesn't have the same sort
Tom Lane wrote:
> David Jarvis writes:
> >> Fair enough. How about something like make_timestamp? It's at least
> >> shorter and easier than construct :-)
>
> > Agreed.
>
> No objection here either.
Added to TODO:
Add function to allow the creation of timestamps using parameters
* htt
On Jun 30, 2010, at 11:12 AM, t...@exquisiteimages.com wrote:
> I read a post
> earlier today that mentioned in passing that it was better to have a
> faster processor than more cores.
This really depends on your workload and how much you value latency vs.
throughput. If you tend to have a lot
On Tue, Jun 29, 2010 at 9:39 PM, Bruce Momjian wrote:
> Jignesh Shah wrote:
>> On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
>> > Tom Lane wrote:
>> >> Bruce Momjian writes:
>> >> >>> I asked on IRC and was told it is true, and looking at the C code it
>> >> >>> looks true. ?What synchro
Thanks for all of the input everyone.
I believe I am going to put together a test case using schemas and
partitioning and then doubling the amount of data currently in the system
to give me an idea of how things will be performing a couple of years down
the road.
I was looking at a server using t
On 6/30/10 9:42 AM, Dave Crooke wrote:
I haven't jumped in yet on this thread, but here goes
If you're really looking for query performance, then any database which
is designed with reliability and ACID consistency in mind is going to
inherently have some mis-fit features.
Some other ideas
I haven't jumped in yet on this thread, but here goes
If you're really looking for query performance, then any database which is
designed with reliability and ACID consistency in mind is going to
inherently have some mis-fit features.
Some other ideas to consider, depending on your query mix
Brad Nicholson wrote:
> > > > Ah, very good point. ?I have added a C comment to clarify why this is
> > > > the current behavior; ?attached and applied.
> > > >
> > > > --
> > > > ?Bruce Momjian ? ? ? ? ?http://momjian.us
> > > > ?EnterpriseDB ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://enterprisedb.com
> >
On Tue, 2010-06-29 at 21:39 -0400, Bruce Momjian wrote:
> Jignesh Shah wrote:
> > On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > >> Bruce Momjian writes:
> > >> >>> I asked on IRC and was told it is true, and looking at the C code it
> > >> >>> looks true. ?What s
Samuel Gendler wrote:
6 internal drives on battery backed raid (I don't know what RAID level
- is there a way to discover this?), all in a single filesystem, so
WAL and data are on the same filesystem. I don't believe that we are
taking advantage of the battery backed controller, since I only se
On Tue, 29 Jun 2010, Samuel Gendler wrote:
The copy statements execute in a small fraction of the minute in which
they occur.
I'm going to ask a silly question here. If the system is already coping
quite well with the load, then why are you changing it?
All old data gets removed by dropping
12 matches
Mail list logo
