On Thu, Jun 15, 2006 at 15:38:32 -0400,
John Vincent <[EMAIL PROTECTED]> wrote:
> Any suggestions? FYI the original question wasn't meant as a poke at
> >comparing PG to MySQL to DB2. I'm not making an yvalue judgements either
> >way. I'm just trying to understand how we can use it the best way p
On Mon, Jul 10, 2006 at 17:55:38 +1000,
Neil Hepworth <[EMAIL PROTECTED]> wrote:
>
> running on our server (obviously we need to update certain queries,
> e.g. delete .. using.. and test with 8.1 first) - I will be pushing
> for an upgrade as soon as possible. And the fsync=false is a
You can
On Wed, Jul 12, 2006 at 10:16:40 -0600,
"Koth, Christian (DWBI)" <[EMAIL PROTECTED]> wrote:
>
> I have noticed a strange performance behaviour using a commit statement on
> two different machines. On one of the machines the commit is many times
> faster than on the other machine which has fast
On Wed, Jul 12, 2006 at 15:41:14 -0500,
Medora Schauer <[EMAIL PROTECTED]> wrote:
> I have just upgraded from 7.3.4 to 8.1.4 and now *all* db access calls
> are extremely slow. I didn't need to preserve any old data so at this
> point all my tables are empty. Just connecting to a db takes sever
On Fri, Jul 21, 2006 at 07:41:02 +,
Alaa El Gohary <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
The report below isn't a bug, its a performance question and should have
been sent to [EMAIL PROTECTED] I am redirecting replies there.
> A query on the postgresql DB
On Tue, Oct 03, 2006 at 12:13:43 -0700,
Graham Davis <[EMAIL PROTECTED]> wrote:
> Also, the multikey index of (assetid, ts) would already be sorted and
> that is why using such an index in this case is
> faster than doing a sequential scan that does the sorting afterwards.
That isn't necessaril
On Wed, Oct 04, 2006 at 10:03:00 +0200,
Luc Delgado <[EMAIL PROTECTED]> wrote:
>
> Please unsubscribe me! Thank you!
If you really can't figure out how to unsubscribe from a list, you should
contact the list owner, not the list. The list members can't unsubscribe you
(and it isn't their job t
On Wed, Oct 04, 2006 at 08:30:03 -0700,
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> Although I 100% agree with you Bruno, it should be noted that our lists
> are a closed box for most people. They don't follow what is largely
> considered standard amongst lists which is to have list informa
On Mon, Oct 09, 2006 at 23:33:03 +0200,
Tobias Brox <[EMAIL PROTECTED]> wrote:
>
> Just a comment from the side line; can't the rough "set
> enable_seqscan=off" be considered as sort of a hint anyway? There have
> been situations where we've actually had to resort to such crud.
That only works
On Tue, Mar 23, 2004 at 11:21:39 -0500,
Phil Endecott <[EMAIL PROTECTED]> wrote:
> Does anyone have any suggestions about how to do this? I'd like a nice
> general technique that works for all possible subqueries, as my current
> composition with INTERSECT does.
One adjustment you might make i
On Mon, Mar 29, 2004 at 12:00:16 -0500,
Fabio Esposito <[EMAIL PROTECTED]> wrote:
>
> I'm sorry all, when you say regular user as opposed to superuser are you
> talking about the user that postgres is installed and running as? Should
> this be done as the os's root?
The os user used for creati
On Fri, Apr 02, 2004 at 01:00:45 +0200,
Palle Girgensohn <[EMAIL PROTECTED]> wrote:
>
> Is it always bad to create index xx on yy (field1, field2, field3);
>
> I guess the problem is that the index might often grow bigger than the
> table, or at least big enough not to speed up the queries?
O
On Mon, Apr 12, 2004 at 17:24:17 +0530,
Rajesh Kumar Mallah <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> Is there any performance penalty of having too many columns in
> a table in terms of read and write speeds.
>
> To order to keep operational queries simple (avoid joins) we plan to
> add c
On Mon, Apr 12, 2004 at 15:05:02 -0400,
Jeremy Dunn <[EMAIL PROTECTED]> wrote:
>
> Agreed. However, given that count(*) is a question that can be answered
> _solely_ using the index (without reference to the actual data blocks),
> I'd expect that the break-even point would be considerably highe
On Wed, Apr 14, 2004 at 21:12:18 +0100,
Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> I guess what I'm saying is it's not how many people you've got working
> on the optimizer, its how many accurate field reports of less-than
> perfect optimization reach them. In that case, PostgreSQL is likely in
On Sun, Apr 18, 2004 at 18:27:09 +0200,
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
> On Sun, 18 Apr 2004, Tom Lane wrote:
>
> > > What do you mean? int8 is supported on all platformas
> >
> > No it isn't.
>
> So on platforms where it isn't you would use int4 as the biggest int then.
> I don'
Please don't reply to messages to start new threads.
On Tue, Apr 20, 2004 at 10:20:05 -0400,
Chris Hoover <[EMAIL PROTECTED]> wrote:
> I need some help. I have a query that refuses to use the provided index and
> is always sequentially scanning causing me large performance headaches. Here
>
On Mon, May 03, 2004 at 18:08:23 +0200,
Timo Nentwig <[EMAIL PROTECTED]> wrote:
>
> This is very slow:
This kind of question should be asked on the performance list.
>
> SELECT urls.id FROM urls WHERE
> (
> urls.id <> ALL (SELECT html.urlid FROM html)
> );
>
> ...while this is quite fa
On Wed, Apr 28, 2004 at 10:13:14 +0200,
Edoardo Ceccarelli <[EMAIL PROTECTED]> wrote:
> do you mean that, declaring an index serial, I'd never have to deal with
> incrementing its primary key? good to know!
That isn't what is happening. Serial is a special type. It is int plus
a default rule li
On Sun, Jun 13, 2004 at 06:21:17 +0300,
Vitaly Belman <[EMAIL PROTECTED]> wrote:
>
> Consider the following query:
>
> select t1field1, avg(t2fieild2)
> from t1, t2
> where t1.field1 = t2.field2
> group by t1field1
>
> That works fine. But I'd really like to see more fields of t1 in this
> que
On Tue, Jun 22, 2004 at 12:31:15 -0500,
Bill <[EMAIL PROTECTED]> wrote:
> Ok, so maybe someone on this group will have a better idea. We have a
> database of financial information, and this has literally millions of
> entries. I have installed indicies, but for the rather computationally
> dema
On Tue, Jun 29, 2004 at 01:37:30 -0700,
Chris Cheston <[EMAIL PROTECTED]> wrote:
> ok i just vacuumed it and it's taking slightly longer now to execute
> (only about 8 ms longer, to around 701 ms).
>
> Not using indexes for calllogs(from)... should I? The values for
> calllogs(from) are not uni
On Tue, Jun 29, 2004 at 10:46:27 +0200,
"Harald Lau (Sector-X)" <[EMAIL PROTECTED]> wrote:
>
> h...
> So, it seems that PG is not s well suited for a datawarehouse and/or performing
> extensive statistics/calculations/reportings on large tables, is it?
If you are doing lots of selects
On Tue, Jun 29, 2004 at 12:33:51 -0500,
Bill <[EMAIL PROTECTED]> wrote:
> Ok, thanks. So let me explain the query number 2 as this is the more
> difficult to write. So I have a list of stocks, this table contains the
> price of all of the stocks at the open and close date. Ok, now we have a
>
On Fri, Jul 02, 2004 at 09:48:48 +0200,
Peter Alberer <[EMAIL PROTECTED]> wrote:
>
> Postgres seems to execute the function "submission_status" for every row
> of
> the submissions table (~1500 rows). The query therefore takes quite a
> lot
> time, although in fact no row is returned from the as
On Fri, Jul 02, 2004 at 04:50:07 -0300,
PostgreSQL Bugs List <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
This doesn't appear to be a bug at this point. It sounds like you have
a self induced performance problem, so I am moving the discussion to
pgsql-performance.
>
On Wed, Aug 04, 2004 at 14:00:39 +0200,
Ulrich Wisser <[EMAIL PROTECTED]> wrote:
This topic really belongs on the performance list. I have copied that
list and set followups to go there and copy you.
>
> my web application grows slower and slower over time. After some
> profiling I came to th
On Fri, Aug 13, 2004 at 08:57:56 -0400,
Rod Taylor <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 08:10, Ulrich Wisser wrote:
> > Hi,
> >
> > my inserts are done in one transaction, but due to some foreign key
> > constraints and five indexes sometimes the 100 inserts will take more
> > th
On Fri, Aug 13, 2004 at 17:17:10 +0100,
Matt Clark <[EMAIL PROTECTED]> wrote:
> > > It is likely that you are missing an index on one of those foreign
> > > key'd items.
> >
> > I don't think that is too likely as a foreign key reference
> > must be a unique key which would have an index.
>
On Fri, Aug 20, 2004 at 13:25:30 -0300,
Danilo Mota <[EMAIL PROTECTED]> wrote:
>
> And the following tables:
> TABLES
>
> --
> == r_cliente: 75816 records
>
On Mon, Aug 30, 2004 at 21:21:26 +0200,
Pierre-Frédéric Caillaud <[EMAIL PROTECTED]> wrote:
> >>Also, count(*) is likely to always generate a seq scan due to the way
> >>aggregates are implemented currently in pgsql. you might want to try:
>
>
> By the way, in an ideal world, count(*) sh
On Thu, Nov 04, 2004 at 22:37:06 +,
Matt Clark <[EMAIL PROTECTED]> wrote:
> >...
>
> Yup. If you go the JS route then you can do even better by using JS to
> load data into JS objects in the background and manipulate the page
> content directly, no need for even an Iframe. Ignore the dul
On Thu, Nov 04, 2004 at 23:32:57 +,
Matt Clark <[EMAIL PROTECTED]> wrote:
> >
> >I think in the future there will be a good bit of presentation
> >login in the client...
>
> Not if Bruno has his way ;-)
Sure there will, but it will be controlled by the client, perhaps taking
suggestio
On Fri, Nov 05, 2004 at 09:39:16 -0500,
Allen Landsidel <[EMAIL PROTECTED]> wrote:
>
> For some reason it's a requirement that partial wildcard searches are
> done on this field, such as "SELECT ... WHERE field LIKE 'A%'"
>
> I thought an interesting way to do this would be to simply create
> p
On Mon, Dec 13, 2004 at 08:28:39 -0800,
sarlav kumar <[EMAIL PROTECTED]> wrote:
>
> Is there a way to write the INSERT as follows?
>
> INSERT into merchant_buyer_country (merchant_id,country,enabled,group_id)
> values (1203,
> (SELECT code FROM country WHERE send IS NOT NULL OR receive IS N
On Fri, Dec 17, 2004 at 14:46:57 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> This looks like it must be a memory leak in the gist indexing code
> (either gist itself or tsearch2). I don't see any post-release fixes in
> the 7.4 branch that look like they fixed any such thing :-(, so it's
> p
On Mon, Dec 13, 2004 at 17:32:02 -0200,
Alvaro Nunes Melo <[EMAIL PROTECTED]> wrote:
> Em Seg, 2004-12-13 às 16:03, Bruno Wolff III escreveu:
> > On Mon, Dec 13, 2004 at 15:17:49 -0200,
> > Alvaro Nunes Melo <[EMAIL PROTECTED]> wrote:
> > > db=> SELECT C
On Fri, Dec 17, 2004 at 22:56:27 +0100,
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
>
> I'm a bit unsure -- should counting ~3 million rows (no OIDs, PG 7.4,
> everything in cache, 32-byte rows) take ~3500ms on an Athlon 64 2800+?
It doesn't seem totally out of wack. You will be limited b
On Mon, Dec 20, 2004 at 06:40:34 -0800,
sarlav kumar <[EMAIL PROTECTED]> wrote:
>
> I would like to do a pg_dump on the test database, and restore it in the new
> database on Postgres 7.4.6. I would like to know if there would be any
> problem due to the postgres version/OS change. If so, cou
On Sun, Dec 26, 2004 at 13:30:15 +0100,
Karl Vogel <[EMAIL PROTECTED]> wrote:
>
> This depends on the version of Oracle you're using. Oracle 9i
> introduced Index Skip Scans:
>
> http://www.oracle.com/technology//products/oracle9i/daily/apr22.html
>
> I don't know whether pg has something si
On Fri, Jan 07, 2005 at 19:36:47 -0800,
"Loren M. Lang" <[EMAIL PROTECTED]> wrote:
> Do large TEXT or VARCHAR entries in postgresql cause any performance
> degradation when a query is being executed to search for data in a table
> where the TEXT/VARCHAR fields aren't being searched themselves?
Y
On Sun, Jan 09, 2005 at 16:45:18 +1100,
"Guenzl, Martin" <[EMAIL PROTECTED]> wrote:
> LOL ... Excuse my ignorance but what's Karnak headear?
Jonny Carson used to do sketches on the Tonight show where he was Karnak
and would give answers to questions in sealed envelopes which would later
be read
On Thu, Jan 20, 2005 at 11:31:29 -0500,
Alex Turner <[EMAIL PROTECTED]> wrote:
> I am curious - I wasn't aware that postgresql supported partitioned tables,
> Could someone point me to the docs on this.
Some people have been doing it using a union view. There isn't actually
a partition feature.
On Thu, Jan 20, 2005 at 11:14:28 +0100,
Bernd Heller <[EMAIL PROTECTED]> wrote:
>
> I wondered why the planner was making such bad assumptions about the
> number of rows to find and had a look at pg_stats. and there was the
> surprise:
> there is no entry in pg_stats for that column at all!! I
On Sat, Jan 22, 2005 at 12:13:00 +0900,
Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>
> Probably VACUUM works well for small to medium size tables, but not
> for huge ones. I'm considering about to implement "on the spot
> salvaging dead tuples".
You are probably vacuuming too often. You want to wa
On Thu, Jan 27, 2005 at 21:17:56 -0800,
Zavier Sheran <[EMAIL PROTECTED]> wrote:
> quote from manual:
> --
> Unfortunately, there is no similarly trivial query
> that can be used to improve the performance of count()
> when applied to the entire table
> --
>
> does count(1) also cause a sequenti
On Fri, Feb 11, 2005 at 02:22:39 -0500,
Jaime Casanova <[EMAIL PROTECTED]> wrote:
> What about the free speech rigths, in USA they are in the constitution
> and cannot be denied or revoked, IANAL.
You can voluntarily give up your rights to free speech in the US.
> And like stated by Mitch just
On Mon, Feb 28, 2005 at 16:46:34 +0100,
Markus Schaber <[EMAIL PROTECTED]> wrote:
> Hi, Matthew,
>
> Matthew T. O'Connor schrieb:
>
> > The version of pg_autovacuum that I submitted for 8.0 could be
> > instructed "per table" but it didn't make the cut. Aside from moved out
> > of contrib and
On Tue, Mar 08, 2005 at 13:35:53 -0500,
Rick Schumeyer <[EMAIL PROTECTED]> wrote:
> I have two index questions. The first is about an issue that has been
> recently discussed,
>
> and I just wanted to be sure of my understanding. Functions like count(),
> max(), etc. will
>
> use sequential s
On Tue, Mar 08, 2005 at 22:55:19 -0600,
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 10:38:21PM -0600, Bruno Wolff III wrote:
> > Not exactly. If the number of rows to be examined is on the order of 5%
> > of the table, an index scan
On Sun, Mar 20, 2005 at 22:39:57 -0500,
Keith Worthington <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have been reading about set returning functions. What I would like to
> know is is there a performance advantage in using SRFs versus querying a
> view. Assuming the underlying SQL is the sam
On Tue, Mar 22, 2005 at 08:09:40 -0500,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>
> Are you certain it's a linear system? I'm not. If it was a matter of
> minimizing a linear expression subject to some set of linear
> equations, then we could model this as a Linear Program for which
> th
On Tue, Jul 22, 2003 at 11:40:35 +0200,
Vincent van Leeuwen <[EMAIL PROTECTED]> wrote:
>
> About RAID types: the fastest RAID type by far is RAID-10. However, this will
> cost you a lot of useable diskspace, so it isn't for everyone. You need at
> least 4 disks for a RAID-10 array. RAID-5 is a n
On Mon, Aug 04, 2003 at 15:05:08 -0600,
"Valsecchi, Patrick" <[EMAIL PROTECTED]> wrote:
> Sir,
>
> I did a search with the "index" keyword on the mailing list archive and it did come
> with no result. Sorry if it's a known bug.
It isn't a bug. It is a design trade off. The database has no spe
On Wed, Aug 20, 2003 at 13:01:16 +0300,
[EMAIL PROTECTED] wrote:
> I have found many reasons not to index small tables (see .
> But I still have questions.
>
> 1. How small is small enough?
Unless you think maintaining the indexes is a significant overhead, you
shouldn't worry about it as the p
On Thu, Aug 28, 2003 at 17:10:31 -0700,
Ken Geis <[EMAIL PROTECTED]> wrote:
> The query I want to run is
>
> select stock_id, min(price_date) from day_ends group by stock_id;
The fast way to do this is:
select distinct on (stock_id) stock_id, price_date
order by stock_id, price_date;
> Also
On Thu, Aug 28, 2003 at 19:50:38 -0700,
Ken Geis <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III wrote:
> >On Thu, Aug 28, 2003 at 17:10:31 -0700,
> > Ken Geis <[EMAIL PROTECTED]> wrote:
> >
> >>The query I want to run is
> >>
> >>sele
On Thu, Aug 28, 2003 at 20:00:32 -0700,
Ken Geis <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III wrote:
> >>Not according to the optimizer! Plus, this is not guaranteed to return
> >>the correct results.
> >
> >For it to be fast you need an index on (stock
On Thu, Aug 28, 2003 at 20:46:00 -0700,
Ken Geis <[EMAIL PROTECTED]> wrote:
>
> A big problem is that the values I am working with are *only* the
> primary key and the optimizer is choosing a table scan over an index
> scan. That is why I titled the email "bad estimates." The table has
> (s
On Thu, Aug 28, 2003 at 21:09:00 -0700,
Ken Geis <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III wrote:
>
> I am positive! I can send a log if you want, but I won't post it to the
> list.
Can you do a \d on the real table or is that too sensitive?
It still doesn'
I haven't come up with any great ideas for this one. It might be interesting
to compare the explain analyze output from the distinct on query with
and without seqscans enabled.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
On Wed, Aug 27, 2003 at 15:50:32 +0300,
Tarhon-Onu Victor <[EMAIL PROTECTED]> wrote:
>
> The problems is that only ~15% of the lines are inserted into
> the database. The same script modified to insert the same data in a
> similar table created in a MySQL database inserts 100%.
Did you
On Tue, Sep 09, 2003 at 12:54:04 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
>
> So what would it take to implement this for "all" aggregates? Where I think
> "all" really just means min(), max(), first(), last().
There can be other aggregates where indexes are helpful. The case of interest
is
On Tue, Sep 09, 2003 at 14:06:56 -0500,
Thomas Swan <[EMAIL PROTECTED]> wrote:
>
> Would it be possible to rewrite min and max at the parser level into a
> select/subselect (clause) condition ( repeat condition ) order by
> (clause ) descending/ascending limit 1 and thereby avoiding the
> penal
On Mon, Sep 15, 2003 at 17:34:12 -0400,
Joseph Bove <[EMAIL PROTECTED]> wrote:
>
> I do a rather simple query: select count (*) from large-table where column
> = some value;
>
> About 80% of the time, the response time is sub-second. However, at 10% of
> the time, the response time is 5 - 10
On Thu, Oct 02, 2003 at 12:15:47 -0700,
Dror Matalon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a somewhat large table, 3 million rows, 1 Gig on disk, and growing. Doing a
> count(*) takes around 40 seconds.
>
> Looks like the count(*) fetches the table from disk and goes through it.
> Made m
saction that hasn't committed
or in the case of serializable isolation, a transaction that committed after
the current transaction started.
>
> On Thu, Oct 02, 2003 at 02:39:05PM -0500, Bruno Wolff III wrote:
> > On Thu, Oct 02, 2003 at 12:15:47 -0700,
> > Dror Matalon
On Fri, Oct 03, 2003 at 15:47:01 -0600,
Rob Nagler <[EMAIL PROTECTED]> wrote:
> > vacuum full does require exclusive lock, plain vacuum does not.
>
> I think I need full, because there are updates on the table. As I
> understand it, an update in pg is an insert/delete, so it needs
> to be garba
On Mon, Oct 06, 2003 at 09:55:51 +0200,
Stef <[EMAIL PROTECTED]> wrote:
>
> Thanks, I'll try some of these, and post the results.
> The actual machines seem to be Pentium I machines,
> with 32M RAM. I've gathered that it is theoretically
> possible, so no to go try it.
I am running 7.4beta2 on
On Thu, Oct 09, 2003 at 17:44:46 -0700,
Dror Matalon <[EMAIL PROTECTED]> wrote:
>
> How is doing order by limit 1 faster than doing max()? Seems like the
> optimizer will need to sort or scan the data set either way. That part
> didn't actually make a difference in my specific case.
max() will
On Thu, Oct 30, 2003 at 12:34:15 +0100,
Cestmir Hybl <[EMAIL PROTECTED]> wrote:
> Are you seeing this question as totally off-topic in this list, or there is
> really no one who knows something about indexing "is null" bits in postgres?
There was some talk about IS NULL not being able to use ind
On Thu, Nov 20, 2003 at 07:07:30 +0530,
Rajesh Kumar Mallah <[EMAIL PROTECTED]> wrote:
>
> If i dump and reload the performance improves and it takes < 1 sec. This
> is what i have been doing since the upgrade. But its not a solution.
>
> The Vacuum full is at the end of a loading batch SQL fil
On Mon, Nov 24, 2003 at 16:03:17 -0600,
MK Spam <[EMAIL PROTECTED]> wrote:
>
> The archives of this list provides many ideas for improving performance, but the
> problem we are having is gradually degrading performance ending in postgres shutting
> down. So it's not a matter of optimizing a c
On Thu, Dec 11, 2003 at 11:00:19 -0500,
sandra ruiz <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I need to know if there is anything like hints of Oracle in
> Postgres..otherwise..I wish to find a way to force a query plan to use the
> indexes or tell the optimizer things like "optimize based in
On Mon, Jan 05, 2004 at 11:33:40 -0500,
Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> Thanks. Then it sorta makes it moot for me to try deferred checks,
> since the Pimary and Foreign keys never change once set. I wonder
> what is making the transactions appear to run lockstep, then...
I think t
On Thu, Jan 08, 2004 at 19:27:16 -0800,
Mike Glover <[EMAIL PROTECTED]> wrote:
>
> You should bump sort_mem as high as you can stand. with only 8MB sort
> memory available, you're swapping intermediate sort pages to disk --
> a lot. Try the query with sort_mem set to 75MB (to do the entire sort
On Wed, Jan 21, 2004 at 09:18:18 -0800,
Ron St-Pierre <[EMAIL PROTECTED]> wrote:
>
> My question is in regards to steps 2 and 3 above. Is there some way that
> I can combine both steps into one to save some time?
TIP 4: Don't 'kill -9' the postmaster
SELECT SS.* FROM
(SELECT DISTINCT ON (nonU
One other suggestion I forgot is that this should move over to the
performance list rather than being on the sql list. The right people
are more likely to see your question there.
On Thu, Jan 29, 2004 at 16:02:06 +0100,
Alexandra Birch <[EMAIL PROTECTED]> wrote:
>
> > >
> > > Postgres choses th
On Tue, Feb 03, 2004 at 13:54:17 +0100,
David Teran <[EMAIL PROTECTED]> wrote:
> Hi,
>
> we are trying to speed up a database which has about 3 GB of data. The
> server has 8 GB RAM and we wonder how we can ensure that the whole DB
> is read into RAM. We hope that this will speed up some queri
This discussion really belongs on the performance list and I am copying
that list with mail-followup-to set.
On Fri, Feb 20, 2004 at 12:26:22 +0530,
V Chitra <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have a select statement
>
> select * from v_func_actual_costs
> where parent_project='10478'
On Mon, Feb 23, 2004 at 19:10:57 -0700,
"Ed L." <[EMAIL PROTECTED]> wrote:
>
> A 7.3.4 question...
>
> I want to "expire" some data after 90 days, but not delete too
> much at once so as not to overwhelm a system with precariously
> balanced disk I/O and on a table with millions of rows. If I
On Mon, Mar 08, 2004 at 11:05:25 -0500,
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
>
> "Intended", no. "Expected", yes. This topic has had the best
> Postgres minds work on it, and so far nobody's come up with a
> solution. There was a proposal to put in a special-case automatic
> fix for int
101 - 182 of 182 matches
Mail list logo
