On 4/14/05, Joel Fradkin <[EMAIL PROTECTED]> wrote:
> I have done a vacuum and a vacuum analyze.
> I can try again for kicks, but it is not in production so no new records are
> added and vacuum analyze is ran after any mods to the indexes.
>
> I am still pursuing Dell on why the monster box is so
On 4/14/05, Joel Fradkin <[EMAIL PROTECTED]> wrote:
> Josh from commandprompt.com had me alter the config to have
> default_statistics_target = 250
>
> Is this somehow related to what your asking me to do?
> I did do an analyze, but have only ran the viw a few times.
well, he did suggest the righ
On 4/15/05, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> a) SELECT items.a, items.b, ..., users.username FROM items, users
> WHERE items.uid = users.uid;
>
> c) CREATE FUNCTION id2username(oid) RETURNS text
> LANGUAGE 'SQL' IMMUTABLE AS '
> SELECT username AS RESULT FROM users W
On 4/18/05, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > d) self-join with a function ;)
> > EXPLAIN ANALYZE SELECT * FROM (SELECT n, id2username(n) AS username
> > FROM (SELECT DISTINCT n FROM aaa) AS values) AS v_lookup RIGHT JOIN
> > aaa USING (n);
>
> That's pretty clever.
> It sure seems l
On 4/20/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> You should re-run the function test using SQL as the function language
> instead of plpgsql. There might be some performance to be had there.
Yay! You're right! I wonder why have I forgotten about LANGUAGE SQL. :)
It's 30 seconds vs 5 seconds
On 4/19/05, Mohan, Ross <[EMAIL PROTECTED]> wrote:
> Clustered file systems is the first/best example that
> comes to mind. Host A and Host B can both request from diskfarm, eg.
Something like a Global File System?
http://www.redhat.com/software/rha/gfs/
(I believe some other company did develop
On 4/21/05, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> > Yeah, I was actually thinking about a two-step process: inline the
> > function to produce somethig equivalent to a handwritten scalar
> > sub-SELECT, and then try to convert sub-SELECTs into joi
On 4/21/05, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
>
> > Even if your data never changes it *can* change so the function should
> > be at most stable not immutable.
>
> okay, the planner sees that the table could potentionally change.
> but - as the dba - I'd like to tell him, this table *neve
On 5/26/05, Josh Close <[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 right now. I'm assuming th
On 6/2/05, Dirk Lutzebäck <[EMAIL PROTECTED]> wrote:
> I just got one reply for this survey. Is almost nobody using postgresql
> on 8+ machines?
My guess is when someone is using PostgreSQL on 8+ machine, she's
in highly competitive (or sensitive) market and either cannot give
company's work detai
On 6/28/05, John A Meinel <[EMAIL PROTECTED]> wrote:
> Actually, if you already have a lower bound, then you can change it to:
>
> SELECT t1.id+1 as id_new FROM id_test t1
> WHERE t1.id > id_min
> AND NOT EXISTS
> (SELECT t2.id FROM id_test t2 WHERE t2.id = t1.id+1)
> ORDE
On 7/7/05, Jean-Max Reymond <[EMAIL PROTECTED]> wrote:
> On my laptop whith Centrino 1.6 GHz, 512 Mb RAM,
> - it is solved in 1h50' for Linux 2.6
> - it is solved in 1h37' for WXP Professionnal ( WXP better
> tan Linux ;-) )
[...]
> I test CPU, memory performance on my laptop and it seems that the
On 7/14/05, Jeffrey W. Baker <[EMAIL PROTECTED]> wrote:
> [reposted due to delivery error -jwb]
>
> I just took delivery of a new system, and used the opportunity to
> benchmark postgresql 8.0 performance on various filesystems. The system
> in question runs Linux 2.6.12, has one CPU and 1GB of s
On 7/15/05, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 16:29:58 -0600,
> Dan Harris <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I tried this one. My ssh keeps getting cut off by a router
> > somewhere between me and the server due to inactivity timeouts, so
> > all I know is
On 7/19/05, Oliver Crosby <[EMAIL PROTECTED]> wrote:
> > We had low resource utilization and poor throughput on inserts of
> > thousands of rows within a single database transaction. There were a
> > lot of configuration parameters we changed, but the one which helped the
> > most was wal_buffers
Hello, I have PostgreSQL 8.0.3 running on a "workstation" with 768 MB
of RAM, under FreeBSD. And I have a 47-milion row table:
qnex=# explain select * from log;
QUERY PLAN
On 7/22/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Dawid Kuroczko <[EMAIL PROTECTED]> writes:
> > qnex=# EXPLAIN SELECT * FROM log NATURAL JOIN useragents LIMIT 1;
>
> > Limit (cost=15912.20..15912.31 rows=1 width=272)
> >-> Hash Join (cost=15912
On 7/22/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> > This is quite strange. The nestloop plan definitely should be preferred
> > in the context of the LIMIT, considering that it has far lower estimated
> > cost. And it is preferred in simple tests for me.
>
> After a suitable period of contemplat
On 7/26/05, Roberto Germano Vieweg Neto <[EMAIL PROTECTED]> wrote:
> My application is using Firebird 1.5.2
>
> My question is:
>
> Postgre SQL will be more faster than Firebird? How much (in percent)?
>
> I need about 20% to 50% more performance at my application.
> Can I get this migratin to p
On 12/26/05, David Lang <[EMAIL PROTECTED]> wrote:
> raid5 writes n+1 blocks not n+n/2 (unless n=2 for a 3-disk raid). you can
> have a 15+1 disk raid5 array for example
>
> however raid1 (and raid10) have to write 2*n blocks to disk. so if you are
> talking about pure I/O needed raid5 wins hands d
Hello, I am wondering if it is safe to assume that
specifying cio mount option is safe with PostgreSQL.
As far as I understand the CIO (AIX Concurrent I/O) means that
filesystem does not serialize access to file blocks. In other
words multiple threads can simultaneously read and write
the file b
On 5/9/06, PFC <[EMAIL PROTECTED]> wrote:
> You might consider just selecting your primary key or a set of
> primary keys to involved relations in your search query. If you
> currently use "select *" this can make your result set very large.
>
> Copying all the result set to the temp. costs you
On 5/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Well, they're not my statistics; they're explain's. You mean there's
a bug in explain? I agree that it makes no sense that the costs don't
differ as much as one would expect, but you can see right there the
numbers of rows for the two tab
On 10/17/06, soni de <[EMAIL PROTECTED]> wrote:
I
didn't understand the "Bitmap Scan" and the sentence "indexes
will be dynamically converted to bitmaps in memory". What does mean by
"Bitmap Scan" in database?
Can anybody help us regarding above query?
Assume you have a table:
CREATE TABLE
I've been wondering...
Suppose we have two tables
CREATE TABLE messages (
message_id serial PRIMARY KEY,
message text NOT NULL
);
CREATE TABLE entries (
entry_id serial PRIMARY KEY,
message_id integer NOT NULL REFERENCES messages
);
And we have a join:
SELECT entry_id,message FROM entri
I have a large table with a column:
ids integer[] not null
most of these entries (over 95%) contain only one array element, some
can contain up to 10 array elements. seqscan is naturally slow. GIST
on int_array works nice, but GIST isn't exactly a speed daemon when it
comes to updating.
So I th
The ext3fs allows to selet type of journalling to be used with
filesystem. Journalling pretty much "mirrors" the work of WAL
logging by PostgreSQL... I wonder which type of journalling
is best for PgSQL in terms of performance.
Choices include:
journal
All data
ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; .
I wonder what are the implications of using this statement,
I know by using, say n=100, ANALYZE will take more time,
pg_statistics will be bigger, planner will take longer time,
on the other hand it will make better decisions... Etc, etc.
I
On Fri, 19 Nov 2004 23:18:51 -0500, David Parker
<[EMAIL PROTECTED]> wrote:
> But, I'm also still interested in the answer to my question: is there
> any reason you could not put an 8.0 tablespace on a RAM disk?
>
> I can imagine doing it by having an initdb run at startup somehow, with
> the idea
On Wed, 5 Jan 2005 22:35:42 +0700, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Now I turn hyperthreading off and readjust the conf . I found the bulb query
> that was :
> update one flag of the table [8 million records which I think not too much]
Ahh, the huge update. Below are my "hints" I'v
On Sat, 22 Jan 2005 12:13:00 +0900 (JST), Tatsuo Ishii
<[EMAIL PROTECTED]> wrote:
> IMO the bottle neck is not WAL but table/index bloat. Lots of updates
> on large tables will produce lots of dead tuples. Problem is, There'
> is no effective way to reuse these dead tuples since VACUUM on huge
> ta
On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc
<[EMAIL PROTECTED]> wrote:
> Here a normal listing of design.product_department_time:
> product_id | department_id | req_time
> +---+--
> 906 | A | 3000
> 906 | C |
On Thu, 27 Jan 2005 12:43:56 -0500, Alexandre Leclerc
<[EMAIL PROTECTED]> wrote:
> On Thu, 27 Jan 2005 17:27:40 +0100, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > On Thu, 27 Jan 2005 10:23:34 -0500, Alexandre Leclerc
> > <[EMAIL PROTECTED]> wrot
On Fri, 28 Jan 2005 10:24:37 -0800, Joe Conway <[EMAIL PROTECTED]> wrote:
> Alexandre Leclerc wrote:
> > I'm a little bit confused on how to install this contirb. I know my
> > contrib package is installed, but I don't know how to make it work in
> > postgresql. (Using 7.4.5-1mdk on Mandrake Linux.
On Tue, 22 Mar 2005 18:22:24 +0900, Layet Benjamin
<[EMAIL PROTECTED]> wrote:
> Can I use an index on a varchar column to optimize the SELECT queries that
> use " column LIKE 'header%' "?
> If yes what is the best tree algotithm to use ?
Yes, that is the correct place. The best tree algorithm
On Mon, 21 Mar 2005 14:59:56 -0800, Josh Berkus wrote:
> > If by not practical you mean, "no one has implemented a multivariable
> > testing approach," I'll agree with you. But multivariable testing is
> > definitely a valid statistical approach to solving just such problems.
> Well, not practical
On Wed, 23 Mar 2005 12:11:56 +0800, Michael Ryan S. Puncia
<[EMAIL PROTECTED]> wrote:
>
> I have an experience using LIKE in a VARCHAR column and select statement
> suffers a lot so I decided to go back in CHAR
>
> Note: my database has about 50 millions records a b tree index
Strange...
Accord
On Thu, Mar 20, 2008 at 8:32 PM, Chris Hoover <[EMAIL PROTECTED]> wrote:
> I just found out that my company is planning on migrating my databases from
> our current ISCSI storage solution to NetApps connected via NFS. I knew
> about the NetApp migration, but always assumed (and shame on me) that I
38 matches
Mail list logo
