Hi!
I'm just wondering, I've got a table that is partitioned into monthly
tables:
media_downloads - media_downloads_MM
I\- id (primary key)
\- created_on (timestamp criteria for the monthly table split)
There are constraints upon the created_on column, all needed insert
instead rules are
Am Sonntag, den 29.10.2006, 10:34 -0500 schrieb Andrew Sullivan:
On Sun, Oct 29, 2006 at 03:08:26PM +, Gavin Hamill wrote:
This is interesting, but I don't understand.. We've done a full restore
from one of these pg_dump backups before now and it worked just great.
Sure I had to
Am Sonntag, den 29.10.2006, 11:43 -0500 schrieb Andrew Sullivan:
On Sun, Oct 29, 2006 at 05:24:33PM +0100, Andreas Kostyrka wrote:
Actually, you need to get the schema from the master node, and can take
the data from a slave. In mixing dumps like that, you must realize that
there are two
Am Montag, den 30.10.2006, 08:18 + schrieb Simon Riggs:
On Sun, 2006-10-29 at 00:28 +0200, Andreas Kostyrka wrote:
Any ideas how to make the optimizer handle partitioned tables more
sensible?
Yes, those are known inefficiencies in the current implementation which
we expect
Am Dienstag, den 31.10.2006, 13:04 +0900 schrieb Leif Mortenson:
Hello,
I have been having a problem with the following query ignoring an index
on the foos.bar column.
SELECT c.id
FROM foos c, bars r
WHERE r.id != 0
AND r.modified_time '2006-10-20 10:00:00.000'
AND r.modified_time =
Am Dienstag, den 31.10.2006, 21:58 -0800 schrieb Ben:
I've got a long-running, update-heavy transaction that increasingly slows
down the longer it runs. I would expect that behavior, if there was some
temp file creation going on. But monitoring vmstat over the life of the
transaction shows
Am Donnerstag, den 02.11.2006, 09:41 -0600 schrieb Scott Marlowe:
Sometimes it's the simple solutions that work best. :) Welcome to the
world of pgsql, btw...
OTOH, there are also non-simple solutions to this, which might make
sense anyway: Install slony, and run your queries against a
The solution for us has been twofold:
upgrade to the newest PG version available at the time while we waited
for our new Opteron-based DB hardware to arrive.
Andreas
Am Freitag, den 03.11.2006, 13:29 + schrieb Richard Huxton:
Cosimo Streppone wrote:
Richard Huxton wrote:
[EMAIL
Am Freitag, den 03.11.2006, 14:38 + schrieb Richard Huxton:
[EMAIL PROTECTED] wrote:
If you can keep your numbers of clients down below the critical
level, you should find the overall workload is fine.
We have at about 600 connections. Is this a case to use a connection
pool
* Cosimo Streppone [EMAIL PROTECTED] [061114 10:52]:
Richard Huxton wrote:
Cosimo Streppone wrote:
Richard Huxton wrote:
The average context switching for this server as vmstat shows is 1
but when the problem occurs it goes to 25.
I seem to have the same exact behaviour for an
* AMIR FRANCO D. JOVEN [EMAIL PROTECTED] [061115 12:44]:
Hi!
Im new to PostgreSQL.
My current project uses PostgreSQL 7.3.4.
Ancient. Upgrade it, especially if it's a new database.
the problem is like this:
I have a table with 94 fields and a select with only one resultset in only
* Carlos H. Reimer [EMAIL PROTECTED] [061128 20:02]:
Hi,
There is an article about Lowering the priority of a PostgreSQL query
(http://weblog.bignerdranch.com/?p=11) that explains how to use the
setpriority() to lower PostgreSQL processes.
I?m wondering how much effective it would be for
* Chris [EMAIL PROTECTED] [061211 07:01]:
select SQL_CALC_FOUND_ROWS userid, username, password from users limit 10;
will do:
select userid, username, password from users limit 10;
and calculate this:
select userid, username, password from users;
and tell you how many rows that
* tsuraan [EMAIL PROTECTED] [061216 18:26]:
I'm writing a webmail-type application that is meant to be used in a
corporate environment. The core of my system is a Postgres database
that is used as a message header cache. The two (relevant) tables
being used are pasted into the end of this
* Richard Huxton dev@archonet.com [070306 12:22]:
2. You can do a COPY from libpq - is it really not possible?
Not really but i have been testing it and inserts are flying (about
10 inserts/sec) !!
What's the problem with the COPY? Could you COPY into one table then insert
from that
* Richard Huxton dev@archonet.com [070306 13:47]:
Andreas Kostyrka wrote:
* Richard Huxton dev@archonet.com [070306 12:22]:
2. You can do a COPY from libpq - is it really not possible?
Not really but i have been testing it and inserts are flying (about
10 inserts/sec) !!
What's
* Andreas Tille [EMAIL PROTECTED] [070322 12:07]:
Hi,
I just try to find out why a simple count(*) might last that long.
At first I tried explain, which rather quickly knows how many rows
to check, but the final count is two orders of magnitude slower.
Which version of PG?
The basic
* Andreas Tille [EMAIL PROTECTED] [070322 13:24]:
On Thu, 22 Mar 2007, Andreas Kostyrka wrote:
Which version of PG?
Ahh, sorry, forgot that. The issue occurs in Debian (Etch) packaged
version 7.4.16. I plan to switch soon to 8.1.8.
I'd recommend 8.2 if at all possible :)
That's
* Mario Weilguni [EMAIL PROTECTED] [070322 15:59]:
Am Donnerstag, 22. März 2007 15:33 schrieb Jonah H. Harris:
On 3/22/07, Merlin Moncure [EMAIL PROTECTED] wrote:
As others suggest select count(*) from table is very special case
which non-mvcc databases can optimize for.
Well, other
* Denis Lishtovny [EMAIL PROTECTED] [070402 09:20]:
Hello All.
I have a lot of tables and indexes in database. I must to determine which
indexes are not using or using seldon in databese . I enabled all posible
statistics in config but a can`t uderstand how to do this.
* Peter Kovacs [EMAIL PROTECTED] [070404 14:40]:
This may be a silly question but: will not 3 times as many disk drives
mean 3 times higher probability for disk failure? Also rumor has it
that SATA drives are more prone to fail than SCSI drivers. More
failures will result, in turn, in more
* Alvaro Herrera [EMAIL PROTECTED] [070404 15:42]:
Peter Kovacs escribió:
But if an individual disk fails in a disk array, sooner than later you
would want to purchase a new fitting disk, walk/drive to the location
of the disk array, replace the broken disk in the array and activate
the
* Joshua D. Drake [EMAIL PROTECTED] [070404 17:40]:
Good point. On another note, I am wondering why nobody's brought up the
command-queuing perf benefits (yet). Is this because sata vs scsi are at
SATAII has similar features.
par here? I'm finding conflicting information on this --
* Charles Sprickman [EMAIL PROTECTED] [070407 00:49]:
On Fri, 6 Apr 2007, [EMAIL PROTECTED] wrote:
On Fri, 6 Apr 2007, Scott Marlowe wrote:
Based on experience I think that on average server drives are more
reliable than consumer grade drives, and can take more punishment.
this I am not
* Jeroen Kleijer [EMAIL PROTECTED] [070421 23:10]:
Hi all,
I'm a bit new to PostgreSQL and database design in general so forgive me
for asking stupid questions. ;-)
I've setup a PostgreSQL database on a Linux machine (2 processor, 1GB
mem) and while the database itself resides on a
* Dan Shea [EMAIL PROTECTED] [070424 19:33]:
Version is PWFPM_DEV=# select version();
version
PostgreSQL 7.4 on i686-pc-linux-gnu,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Only some problems that come to my mind with this:
a) Hardware is sometimes changed underhand without telling the customer.
Even for server-level hardware. (Been there.)
b) Hardware recommendations would get stale quickly. What use is a
hardware
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think you'll have to stick with doing your sorting (or merging) in
your client. Don't think that PG recognizes the fact it's just a merge step.
Andreas
Ambrus Wagner (IJ/ETH) wrote:
Dear All,
I have several tables containing data sorted by 2
I'm writing a full report, but I'm having a
lot of problems with MySQL,
I'd like to give it a fair chance, but it shows
real obstination in NOT
working.
Well that matches up well with my experience, better even yet, file a
performance bug to the commercial support and you'll
Consider table partitioning (it's described in the manual).
Andreas
-- Ursprüngl. Mitteil. --
Betreff:[PERFORM] Drop table vs Delete record
Von:Orhan Aglagul [EMAIL PROTECTED]
Datum: 22.05.2007 18:42
My application has two threads, one inserts thousands of records per
You forgot pulling some RAID drives at random times to see how the hardware
deals with the fact. And how it deals with the rebuild afterwards. (Many RAID
solutions leave you with worst of both worlds, taking longer to rebuild than a
restore from backup would take, while at the same ime
TOASTed means storage outside of the main table. But AFAIK, only rows bigger 2K
are considered for toasting.
Andreas
-- Ursprüngl. Mitteil. --
Betreff:Re: My quick and dirty solution (Re: [PERFORM] Performance
Problem with Vacuum of bytea table (PG 8.0.13))
Von:Bastian Voigt [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zoltan Boszormenyi wrote:
Joshua D. Drake írta:
Zoltan Boszormenyi wrote:
Dave Cramer írta:
It's an IBM x3850 using linux redhat 4.0
Isn't that a bit old? I have a RedHat 4.2 somewhere
that was bundled with Applixware 3. :-)
He means redhat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Most of our data is replicated offline using custom tools tailored to
our loading pattern, but we have a small amount of global information,
such as user signups, system configuration, advertisements, and such,
that go into a single small (~5-10
different. one is for all kinds of
scheduled maintenance, while the other is what you do when you've got a
hardware failure.
Andreas
-- Ursprüngl. Mitteil. --
Betreff:Re: [PERFORM] Replication
Von:Craig James [EMAIL PROTECTED]
Datum: 15.06.2007 01:48
Andreas Kostyrka wrote:
Slony
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's even harder, as Oracle disallows publishing benchmark figures in
their license. As a cynic, I might ask, what Oracle is fearing?
Andreas
Jonah H. Harris wrote:
On 6/18/07, David Tokmatchi [EMAIL PROTECTED] wrote:
Scalability ? Performance?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonah H. Harris wrote:
On 6/18/07, Andreas Kostyrka [EMAIL PROTECTED] wrote:
As a cynic, I might ask, what Oracle is fearing?
As a realist, I might ask, how many times do we have to answer this
type of anti-commercial-database flamewar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
PFC wrote:
2. Oracle, Microsoft, and IBM have a lot to fear in the sense of a
database like PostgreSQL. We can compete in 90-95% of cases where
people would traditionally purchase a proprietary system for many,
many thousands (if not hundreds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonah H. Harris wrote:
All of us have noticed the anti-MySQL bashing based on problems with
MySQL 3.23... Berkus and others (including yourself, if I am correct),
have corrected people on not making invalid comparisons against
ancient
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonah H. Harris wrote:
Certainly, but can one expect to get a realistic answer to an, is
Oracle fearing something question on he PostgreSQL list? Or was it
just a backhanded attempt at pushing the topic again? My vote is for
the latter; it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kurt Overberg wrote:
OOookay. Since the discussion has wandered a bit I just
wanted to restate things in an effort to clear the problem in my head.
Okay, so the sl_log_1 TABLE looks okay. Its the indexes that seem to be
messed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wasn't it select pg_start_backup('backuplabel');?
Andreas
Kurt Overberg wrote:
You can use the psql command line to run:
select pg_start_backup();
...then when you're done,
select pg_stop_backup();
if you want an example from the unix
Well, that's not completely trivial = the plan might depend upon the concrete
value of $1,$2 and $3.
Andreas
-- Ursprüngl. Mitteil. --
Betreff:[PERFORM] PREPARE and stuff
Von:PFC [EMAIL PROTECTED]
Datum: 23.06.2007 21:31
Suppose a web application with persistent
Two points:
* need more information about the circumstances.
* could it be that autovaccum hits you?
Andreas
-- Ursprüngl. Mitteil. --
Betreff:[PERFORM] PostgreSQL 8.0 occasionally slow down
Von:Ho Fat Tsang [EMAIL PROTECTED]
Datum: 28.06.2007 06:56
Hi,
I am new for
Am Mittwoch, den 02.04.2008, 20:10 +0100 schrieb James Mansion:
It strikes me as odd that fsync_writethrough isn't the most preferred
option where
it is implemented. The postgres approach of *requiring* that there be no
cache
below the OS is problematic, especially since the battery backup
45 matches
Mail list logo
