> Let me guess, you've updated it a lot and aren't familiar with Vacuum?
>
> run a vacuum full on your database. schedule a vacuum (plain one) to
> run every so often (hours or days are a good interval for most folks)
>
> If that's NOT your problem, then please, let us know.
Scot, thank you. Exce
UPDATE firma1.rid SET toode=NULL
WHERE toode IS NOT NULL AND
toode NOT IN (SELECT TOODE FROM firma1.TOODE);
Why not use a LEFT JOIN for this ?
---(end of broadcast)---
TIP 5: don't forget to increase your free space
> Why not use a LEFT JOIN for this ?
UPDATE firma1.rid SET rid.toode=NULL
LEFT join firma1.toode using(toode)
WHERE rid.toode IS NOT NULL AND toode.toode IS NULL;
Causes:
ERROR: syntax error at or near "LEFT" at character 41
outer joins are not supported in Postgres UPDATE command.
A
outer joins are not supported in Postgres UPDATE command.
True (and sad).
You can try the following script to play with the various options :
DROP TABLE one;
DROP TABLE two;
CREATE TABLE one (a SERIAL PRIMARY KEY, b INT NULL);
CREATE TABLE two (b INT NOT NULL PRIMARY KEY);
IN
"Andrus" <[EMAIL PROTECTED]> writes:
> UPDATE firma1.rid SET toode=NULL
> WHERE toode IS NOT NULL AND
> toode NOT IN (SELECT TOODE FROM firma1.TOODE);
> How to speed this up ?
Increasing work_mem to the point where you get a hashed NOT-IN would
help, probably. Have you tried
Greetings -
I am testing a Sun
Microsystems Sun Fire T2000 demo server at our company. I want to
know if anyone here has any experience with this hardware and postgresql
8.1.3. I installed the copy of postgresql 8.1.3 from blastwave.org onto
this demo box and loaded our production datab
"Juan Casero \(FL FLC\)" <[EMAIL PROTECTED]> writes:
> ... This box has a single Ultrasparc T1 cpu with six execution
> piplelines that can each handle 4 threads. With the Unix top utility
> the postgresql server appears to bounce around between the available
> threads on the system.
Try sending
Juan,
On 4/5/06 11:12 AM, "Juan Casero (FL FLC)" <[EMAIL PROTECTED]>
wrote:
> I know the postgresql server is not smp aware but I believe
> parts of it are. In particular the buffer manager is supposed to scale the
> performance almost linearly with the number of cpu's (including virtual ones).
I am not sure about this. I mean I have postgresql 8.1.3 running on my
Windows XP P4 HT laptop that I use for testing my webapps. When I hit
this pgsql on this laptop with a large query I can see the load spike up
really high on both of my virtual processors. Whatever, pgsql is doing
it looks li
Juan,
On 4/5/06 1:54 PM, "Juan Casero (FL FLC)" <[EMAIL PROTECTED]>
wrote:
> I am not sure about this. I mean I have postgresql 8.1.3 running on my
> Windows XP P4 HT laptop that I use for testing my webapps. When I hit
> this pgsql on this laptop with a large query I can see the load spike up
Luke Lonergan wrote:
> Chris,
>
> On 4/5/06 2:31 PM, "Chris Mair" <[EMAIL PROTECTED]> wrote:
>
> > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > wal_sync_method = fsync (unchanged)
> > wal_buffers = 128 (was 8)
> > checkpoint_segments = 128 (was 3)
> > bgwriter_all_perc
Juan,
On 4/5/06 2:45 PM, "Juan Casero (FL FLC)" <[EMAIL PROTECTED]>
wrote:
> Do you think bizgres might be a good choice of database server for the
> Ultrasparc T1 based T2000? I have downloaded the source code but I was
> hoping to find out if the potential performance gains were worth the
> e
Juan,
> When I hit
> this pgsql on this laptop with a large query I can see the load spike up
> really high on both of my virtual processors. Whatever, pgsql is doing
> it looks like both cpu's are being used indepently.
Nope, sorry, you're being decieved. Postgres is strictly one process, on
On Apr 4, 2006, at 10:41 AM, Vivek Khera wrote:
On Apr 3, 2006, at 10:10 PM, Mark Kirkwood wrote:
I've always left them on, and never had any issues...(even after
unscheduled power loss - which happened here yesterday). As I
understand it, the softupdate code reorders *metadata* operations,
Josh Berkus writes:
> Juan,
>> When I hit
>> this pgsql on this laptop with a large query I can see the load spike up
>> really high on both of my virtual processors. Whatever, pgsql is doing
>> it looks like both cpu's are being used indepently.
> Nope, sorry, you're being decieved. Postgres
josh@agliodbs.com (Josh Berkus) writes:
> Juan,
>
>> When I hit
>> this pgsql on this laptop with a large query I can see the load spike up
>> really high on both of my virtual processors. Whatever, pgsql is doing
>> it looks like both cpu's are being used indepently.
>
> Nope, sorry, you're bein
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent = 0 (was 0.333)
> > > bgwriter_all_maxpages = 0 (was 5)
> > > and leaving everyt
Chris Mair wrote:
Hi,
thanks for all replys.
I've done a few tests.
Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.
Sure - forcedirectio on the entire $PGDATA is a definite loss, you only
want i
appears this didn't make it to the list... resending to the list
directly...
---
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent =
Juan, I think that AMD Opteron is more flex (OS and Hardware Upgrade)
and then, the best solution.¹
What are you think about the Sun Fire X64 X4200 Server?
Take a look in this analysis and performance benchmark².
Regards,
MTada
¹ http://www.anandtech.com/systems/showdoc.aspx?i=2727&p=2
² http
Luke (or anyone else who may be following this thread)
Do you think bizgres might be a good choice of database server for the
Ultrasparc T1 based T2000? I have downloaded the source code but I was
hoping to find out if the potential performance gains were worth the
effort to compile and install
[EMAIL PROTECTED] ("Juan Casero \(FL FLC\)") writes:
> I am not sure about this. I mean I have postgresql 8.1.3 running on
> my Windows XP P4 HT laptop that I use for testing my webapps. When
> I hit this pgsql on this laptop with a large query I can see the
> load spike up really high on both of
Juan Casero (FL FLC) wrote:
> When I hit
> this pgsql on this laptop with a large query I can see the load spike up
> really high on both of my virtual processors. Whatever, pgsql is doing
> it looks like both cpu's are being used indepently.
Intel HT was partly a marketing thing, you don't real
Alvaro,
On 4/5/06 2:48 PM, "Alvaro Herrera" <[EMAIL PROTECTED]> wrote:
> This essentially means stopping all bgwriter activity, thereby deferring
> all I/O until checkpoint. Was this considered? With
> checkpoint_segments to 128, it wouldn't surprise me that there wasn't
> any checkpoint execut
On Wed, 2006-04-05 at 15:54, Juan Casero (FL FLC) wrote:
> I am not sure about this. I mean I have postgresql 8.1.3 running on my
> Windows XP P4 HT laptop that I use for testing my webapps. When I hit
> this pgsql on this laptop with a large query I can see the load spike up
> really high on bot
> > I've done a few tests.
> >
> > Remounting the fs where $PGDATA lives with "forcedirectio"
> > (together with logging, that is default) did not help
> > (if not harm...) performance.
> >
> >
>
> Sure - forcedirectio on the entire $PGDATA is a definite loss, you only
> want it on $PGDATA/pg_
Hi Juan Casero,
I've found that serial query clients are best served by PostgreSQL
running on fast single or dual core processors, ( such as the Athlon
FX60 ) rather than expensive n-way systems. I was orginally using an
8-way Xeon computer for a similar serial throughput problem. and i
wasn't
Tom is right. Unless your workload can generate lots of simultaneous
queries, you will not reap the full benefit of the Sun Fire T2000
system. I have tested 8.1.3 with an OLTP workload on an 8 cores system.
With 1500-2000 client connections, the CPU was only about 30% utilized.
The UltraSPARC T
I am evaluating this SunFire T2000 as a replacement for an Intel P3 1Ghz
postgresql server. This intel server runs a retail reporting database
on postgresql 8.1.3. I need to realize significant performance gains on
T2000 server to justify the expense. So I need to tune the postgresql
server as m
Juan,
On 4/5/06 5:33 PM, "Juan Casero (FL FLC)" <[EMAIL PROTECTED]>
wrote:
> ... but I am looking to see if the performance
> benefit we can get from this server is worth the price tag right now.
While many people here will look forward to performance results on the
T2000, I can guarantee that y
Juan Casero (FL FLC) wrote:
I can't fully realize
the performance benefits of the T2000 server unless and until I start
getting lots of people hitting the database server with requests. This
doesn't happen right now. It may happen later on as I write more
applications for the server but I am l
Luke Lonergan wrote:
Juan,
On 4/5/06 5:33 PM, "Juan Casero (FL FLC)" <[EMAIL PROTECTED]>
wrote:
... but I am looking to see if the performance
benefit we can get from this server is worth the price tag right now.
While many people here will look forward to performance results on the
T2000, I
Leigh,
On 4/5/06 9:23 PM, "Leigh Dyer" <[EMAIL PROTECTED]> wrote:
> We've got a Sun Fire V40z and it's quite a nice machine -- 6x 15krpm
> drives, 4GB RAM, and a pair of Opteron 850s. This gives us more than
> enough power now for what we need, but it's nice to know that we can
> shoehorn a lot m
Chris Mair wrote:
(but note the other mail about wal_sync_method = fsync)
Yeah - looks good! (is the default open_datasync still?). Might be worth
trying out the fdatasync method too (ISTR this being quite good... again
on Solaris 8, so things might have changed)!
Cheers
Mark
Luke Lonergan wrote:
Leigh,
On 4/5/06 9:23 PM, "Leigh Dyer" <[EMAIL PROTECTED]> wrote:
We've got a Sun Fire V40z and it's quite a nice machine -- 6x 15krpm
drives, 4GB RAM, and a pair of Opteron 850s. This gives us more than
enough power now for what we need, but it's nice to know that we can
Hi,
thanks for all replys.
I've done a few tests.
Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.
Doing what http://blogs.sun.com/roller/page/jkshah suggests:
wal_sync_method = fsync (unchanged)
w
> > Yeah - looks good! (is the default open_datasync still?). Might be worth
> > trying out the fdatasync method too (ISTR this being quite good... again
> > on Solaris 8, so things might have changed)!
>
> I was just talking to a member of the Solaris-UFS team who recommended that
> we
> test
Chris,
On 4/5/06 2:31 PM, "Chris Mair" <[EMAIL PROTECTED]> wrote:
> Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> wal_sync_method = fsync (unchanged)
> wal_buffers = 128 (was 8)
> checkpoint_segments = 128 (was 3)
> bgwriter_all_percent = 0 (was 0.333)
> bgwriter_all_ma
Ok that is beginning to become clear to me. Now I need to determine if
this server is worth the investment for us. Maybe it is not a speed
daemon but to be honest the licensing costs of an SMP aware RDBMS is
outside our budget. When postgresql starts does it start up a super
server process and t
Chris,
> Remounting the fs where $PGDATA lives with "forcedirectio"
> (together with logging, that is default) did not help
> (if not harm...) performance.
Not all of PG. JUST pg_xlog. forcedirectio is only a good idea for the xlog.
> Quickly playing around with wal_buffers on Linux and Mac OS
Mark, Chris,
> Yeah - looks good! (is the default open_datasync still?). Might be worth
> trying out the fdatasync method too (ISTR this being quite good... again
> on Solaris 8, so things might have changed)!
I was just talking to a member of the Solaris-UFS team who recommended that we
test fd
Leigh Dyer wrote:
Luke Lonergan wrote:
Leigh,
On 4/5/06 9:23 PM, "Leigh Dyer" <[EMAIL PROTECTED]> wrote:
We've got a Sun Fire V40z and it's quite a nice machine -- 6x 15krpm
drives, 4GB RAM, and a pair of Opteron 850s. This gives us more than
enough power now for what we need, but it's nice
Juan,
> Ok that is beginning to become clear to me. Now I need to determine if
> this server is worth the investment for us. Maybe it is not a speed
> daemon but to be honest the licensing costs of an SMP aware RDBMS is
> outside our budget.
You still haven't explained why you want multi-threa
43 matches
Mail list logo
