of PG pointing at the same files, one
read-only and one read-write with different memory profiles, so I
assume my only real option is throw more RAM at it. I don't have $$$
for another array/server for a master/slave right now. Or perhaps
tweaking my .conf file? Are newer PG versions
On Thu, Oct 7, 2010 at 12:02 PM, Stephen Frost wrote:
> * Aaron Turner (synfina...@gmail.com) wrote:
>> Basically, each connection is taking about 100MB resident
>
> Errr.. Given that your shared buffers are around 100M, I think you're
> confusing what you see in top wi
On Thu, Oct 7, 2010 at 2:47 PM, Greg Smith wrote:
> Aaron Turner wrote:
>>
>> Are newer PG versions more memory efficient?
>>
>
> Moving from PostgreSQL 8.1 to 8.3 or later should make everything you do
> happen 2X to 3X faster, before even taking into account
0rpm) for WAL
other then throwing more spindles at the problem, any suggestions?
Thanks,
Aaron
--
Aaron Turner
http://synfin.net/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On 2/10/06, hubert depesz lubaczewski <[EMAIL PROTECTED]> wrote:
> On 2/10/06, Aaron Turner <[EMAIL PROTECTED]> wrote:
> > So I'm trying to figure out how to optimize my PG install (8.0.3) to
> > get better performance without dropping one of my indexes.
> > B
On 2/10/06, Matthew T. O'Connor wrote:
> Aaron Turner wrote:
> > So I'm trying to figure out how to optimize my PG install (8.0.3) to
> > get better performance without dropping one of my indexes.
>
> What about something like this:
>
> begin;
> drop s
On 2/11/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 09:24:39AM -0800, Aaron Turner wrote:
> > On 2/10/06, Matthew T. O'Connor wrote:
> > > Aaron Turner wrote:
> >
> > Basically, I need some way to optimize PG so that I don
the transaction due to drop index.
Yep. In my case it's not a huge problem right now, but I know it will
become a serious one sooner or later.
Thanks a lot Marc. Lots of useful info.
--
Aaron Turner
http://synfin.net/
---(end of broadcast)---
TIP 6: explain analyze is your friend
On 2/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Aaron Turner <[EMAIL PROTECTED]> writes:
> > Well before I go about re-architecting things, it would be good to
> > have a strong understanding of just what is going on. Obviously, the
> > unique index on the char
most of the settings in the postgresql.conf actually
dropped performance significantly. Looks like I'm starving the disk
cache.
4) I'm going to assume going to a bytea helped some (width is 54 vs
66) but nothing really measurable
Thanks everyone for your help!
--
Aaron Turner
ht
ving your DB box 5 hops away is going to add a lot of latency
and any packet loss is going to kill TCP throughput- especially if you
increase window sizes. I'd recommend something like "mtr" to map the
network traffic (make sure you run it both ways in case you have an
asymmetric routing
a problem, but if the sender is stalling because it has a
small window, waiting for an ack to be received that could cause a
large slow down.
Do the ack's include any data? If so it's indicative of the PG
networking protocol overhead- probably not much you can do about that.
Without looking
E CASCADE
As you see, the sequence scan on pcap_store is killing me, even though
there appears to be a perfectly good index. Is there a better way
construct this query?
Thanks,
Aaron
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Win
On Tue, Jun 16, 2009 at 2:37 PM, Alvaro
Herrera wrote:
> Aaron Turner escribió:
>> I'm trying to figure out how to optimize this query (yes, I ran
>> vacuum/analyze):
>>
>> musecurity=# explain DELETE FROM muapp.pcap_store WHERE pcap_storeid
>
On Tue, Jun 16, 2009 at 5:30 PM, Robert Haas wrote:
> On Tue, Jun 16, 2009 at 7:39 PM, Aaron Turner wrote:
>> On Tue, Jun 16, 2009 at 2:37 PM, Alvaro
>> Herrera wrote:
>>> Aaron Turner escribió:
>>>> I'm trying to figure out how to optimize th
On Tue, Jun 16, 2009 at 6:36 PM, Robert Haas wrote:
> On Tue, Jun 16, 2009 at 9:23 PM, Aaron Turner wrote:
>> DELETE FROM muapp.pcap_store AS x
>> USING muapp.pcap_store AS a
>> LEFT JOIN muapp.pcap_store_log b ON a.pcap_storeid =
>> b.pcap_s
On Tue, Jun 16, 2009 at 6:36 PM, Robert Haas wrote:
> On Tue, Jun 16, 2009 at 9:23 PM, Aaron Turner wrote:
>> DELETE FROM muapp.pcap_store AS x
>> USING muapp.pcap_store AS a
>> LEFT JOIN muapp.pcap_store_log b ON a.pcap_storeid =
>> b.pcap_s
17 matches
Mail list logo
