Hi
I am looking for some references to literature. While we have used
PostgreSQL in the past for a fair number of smaller projects, we are
now starting to use it on a larger scale and hence need to get into
issues of performance optimisation and tuning. While I am OK with using
the EXPLAIN
I'm getting weird results for one of my queries. The actual time of this
index scan doesn't make any sense:
- Index Scan using dok_dok_fk_i on dokumendid a (cost=0.00..566.24
rows=184 width=8) (actual time=0.170..420806.563 rows=1 loops=1)
dok_dok_fk_i is index on dokumendid(dok_dok_id).
On Tue, Mar 29, 2005 at 05:52:58PM -0700, Karim Nassar wrote:
I recently pg_dumpall'd my DB from a (used for testing) v20z install of
postgresql 8.0.1, and restored it to my production (but not yet in
service) v40z running the same version. The test DB has had multiple
millions of rows
On Wed, Mar 30, 2005 at 12:07:29PM +0100, Marc Burgauer wrote:
What books or sources are out there that I can buy/download and that I
should read to get to grips with the more advanced issues of running
PostgreSQL?
See the Power PostgreSQL Performance Configuration documents:
[EMAIL PROTECTED] wrote on 03/30/2005 10:58:21 AM:
Allow telecommute from across the pond and I might be interested :-)
Please post phone bills to this list.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 3: if
VOIP over BitTorrent?
;-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, March 30, 2005 11:27 AM
To: Michael Fuhr
Cc: Marc Burgauer; pgsql-performance@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Reading
Mohan, Ross wrote:
VOIP over BitTorrent?
Now *that* I want to see. Aught to be at least as interesting
as the TCP/IP over carrier pigeon experiment - and more
challenging to boot!
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
Yea, the upside is that you get better than the 1 byte/hour rate for
pigeon-net.
Downside is that simply because you use BiTorrent, the RIAA accuses you of
everything from CD piracy to shipping pr*n to cyberterrorism, and you spend
the next four years in Gitmo, comparing notes with your
Hi All,
I am developing a simple set returning function as my first step towards more
complicated processes. I would like to understand the implications of using
the dynamic query capability.
I have built two forms of an identically performing function. The first uses
a simple
Hi,
1) seems that the table is a view, I am wrong? If this is true, please
give a query to that table, and try to guess if there is already a bottleneck
there.
2) Add to the query an order by and try to find if it works better.
3) If you drop the index, and no other index exists, it will
On Wed, Mar 30, 2005 at 16:39:47 -,
Mohan, Ross [EMAIL PROTECTED] wrote:
VOIP over BitTorrent?
Plain VOIP shouldn't be a problem. And if you want to do tricky things
you can use Asterisk on both ends. Asterisk is open source (GPL, duel
licensed from Digium) and runs on low powered linux
Keith Worthington wrote:
Hi All,
I am developing a simple set returning function as my first step towards more
complicated processes. I would like to understand the implications of using
the dynamic query capability.
I have built two forms of an identically performing function. The first uses
a
which is evaluated and replanned on each entry to the
FOR loop. This allows the programmer to choose the speed
On each entry is not the same as on each iteration. It would means every
time the loop is started...
Regards,
PFC
---(end of
It was very challenging. I worked on the credit window sizing and
retransmission timer estimation algorithms. We took into account weather
patterns, size and age of the bird, feeding times, and the average number
of times a bird circles before determining magnetic north. Interestingly,
packet
Setting join_collapse_limit=1 improves my performance dramatically.
Even on a query with only 3 tables.
This surprised me, since there are only 3 tables being joined, I would
have assumed that the optimizer would have done the exhaustive search
and not used geqo stuff - and that this exhaustive
[EMAIL PROTECTED] wrote:
Mohan, Ross wrote:
VOIP over BitTorrent?
Now *that* I want to see. Aught to be at least as interesting
as the TCP/IP over carrier pigeon experiment - and more
challenging to boot!
It was very challenging. I worked on the credit window sizing and
retransmission
I just wanted to follow up and let everyone know that the biggest
improvement in performance came from moving the pg_xlog directory to
another filesystem (different set of disks) separate from the data
directory.
Thanks for the suggestions.
--
Brandon
---(end of
Florin Andrei wrote:
Hardware: relatively modern Intel CPU, OS and database each on its own
IDE hard-drive (separate IDE cables). Enough memory, i think, but i
can't add too much (not beyond 1GB).
Software: Linux-2.6, pgsql-8.0.1
Function: Essentially a logging server. There are two applications
On Wed, 2005-03-30 at 17:50 -0800, Florin Andrei wrote:
Function: Essentially a logging server. There are two applications (like
syslog) on the same box that are logging to pgsql, each one to its own
database. There are a few tables in one DB, and exactly one table in the
other.
Most of the
Florin Andrei wrote:
On Wed, 2005-03-30 at 17:50 -0800, Florin Andrei wrote:
Function: Essentially a logging server. There are two applications (like
syslog) on the same box that are logging to pgsql, each one to its own
database. There are a few tables in one DB, and exactly one table in the
On Wed, 2005-03-30 at 19:59 -0600, John Arbash Meinel wrote:
Put pg_xlog onto the same drive as the OS, not the drive with the database.
I forgot to mention: the OS drive is purposefully made very slow - the
write cache is turned off and the FS is Ext3 with data=journal. Is then
still ok to put
On Wed, 2005-03-30 at 20:11 -0600, John Arbash Meinel wrote:
Florin Andrei wrote:
For performance reasons, i was thinking to keep the tables append-only,
and simply rotate them out every so often (daily?) and delete those
tables that are too old. Is that a good idea?
If you aren't doing
Florin Andrei wrote:
On Wed, 2005-03-30 at 19:59 -0600, John Arbash Meinel wrote:
Put pg_xlog onto the same drive as the OS, not the drive with the database.
I forgot to mention: the OS drive is purposefully made very slow - the
write cache is turned off and the FS is Ext3 with data=journal. Is
Florin Andrei wrote:
On Wed, 2005-03-30 at 20:11 -0600, John Arbash Meinel wrote:
Florin Andrei wrote:
For performance reasons, i was thinking to keep the tables append-only,
and simply rotate them out every so often (daily?) and delete those
tables that are too old. Is that a good idea?
If you
[EMAIL PROTECTED] writes:
select *
from streetname_lookup as sl
join city_lookup as cl on (true)
left outer join tlid_smaller as ts on (sl.geo_streetname_id =
ts.geo_streetname_id and cl.geo_city_id=ts.geo_city_id)
where str_name='alamo' and city='san antonio' and
Tom Lane wrote:
[EMAIL PROTECTED] writes:
select *
from streetname_lookup as sl
join city_lookup as cl on (true)
left outer join tlid_smaller as ts on (sl.geo_streetname_id =
ts.geo_streetname_id and cl.geo_city_id=ts.geo_city_id)
where str_name='alamo' and city='san antonio'
I can see that PG'ers have a wicked sense of humor.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Wampler
Sent: Wednesday, March 30, 2005 3:58 PM
To: [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Reading
27 matches
Mail list logo
