On 6/8/05, Francisco Figueiredo Jr. <[EMAIL PROTECTED]> wrote:
>
> --- Josh Close <[EMAIL PROTECTED]> escreveu:
>
> > Well, that would make total sense. I was kinda curious how the data
> > provider differentianted between :a and casting like now()::text.
>
On 5/31/05, Martin Fandel <[EMAIL PROTECTED]> wrote:
> In the documentation of
> http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
> is the shared_buffers set to 1/3 of the availble RAM. You're set
> 5*8/1024=391 MB SHMEM. The effective_cache_size in your
> configuration is 45
I didn't see iostat as available to install, but I'm using dstat to see this.
The server has constant disk reads averaging around 50M and quite a
few in the 60M range. This is when selects are being done, which is
almost always. I would think if postgres is grabbing everything from
memory that thi
96.10 rows=56891 width=4)
Filter: ((tstamp)::text > ((now() - '00:05:00'::interval))::text)
Still not an index scan.
On 5/27/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Josh Close <[EMAIL PROTECTED]> writes:
> > this_sQuery := \'
> >
> I think you really want that seqscan to be an indexscan, instead.
> I'm betting this is PG 7.4.something? If so, probably the only
> way to make it happen is to simplify the now() expression to a constant:
>
> SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
> FROM adap
> Few "mandatory" questions:
>
> 1. Do you vacuum your db on regular basis? :)
It's vacuumed once every hour. The table sizes and data are constantly changing.
>
> 2. Perhaps statistics for tables in question are out of date, did you
> try alter table set statistics?
No I haven't. What would
On 5/26/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> > I have some queries that have significan't slowed down in the last
> > couple days. It's gone from 10 seconds to over 2 mins.
> >
> > The cpu has never gone over 35% in the servers lifetime, but the load
> > average is over 8.0 righ
> Setting shared buffers above something like 10-30% of memory is counter
> productive.
What is the reason behind it being counter productive? If shared
buffers are at 30%, should effective cache size be at 70%? How do
those two relate?
>
> Increasing sort_mem can help with various activities, b
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm assuming this is probably due to
disk io.
I need some help setting up
On Tue, 19 Oct 2004 22:23:24 -0700, Josh Berkus <[EMAIL PROTECTED]> wrote:
> There have been issues with Postgres+HT, especially on Linux 2.4. Try
> turning HT off if other tuning doesn't solve things.
>
> Otherwise, see:
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
How would
On Wed, 20 Oct 2004 00:35:31 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> I suspect that fooling with shared_buffers is entirely the wrong tree
> for you to be barking up. My suggestion is to be looking at individual
> queries that are slow, and seeing how to speed those up. This might
> involve
On Wed, 20 Oct 2004 01:33:16 +0100, Simon Riggs <[EMAIL PROTECTED]> wrote:
> and using what version of PostgreSQL are you using? 8.0beta, I hope?
I'm using version 7.4.5.
> > I was thinking I need to increase the amount of shared buffers, but
> > I've been told "the sweet spot for shared_buff
I'm trying to figure out what I need to do to get my postgres server
moving faster. It's just crawling right now. It's on a p4 HT with 2
gigs of mem.
I was thinking I need to increase the amount of shared buffers, but
I've been told "the sweet spot for shared_buffers is usually on the
order of 100
13 matches
Mail list logo
