David Griffiths <[EMAIL PROTECTED]> writes:
> Is there a size limit to an email
IIRC, the standard policy on the pgsql lists is that messages over 40K
or so will be delayed for moderator approval. However, you should have
gotten immediate replies from the majordomo 'bot telling you so. If you
go
I've posted several emails, and have yet to see one
show up (this one might not either).
Is there a size limit to an email (it had a big
analyze, and schema information)??
David
\Palle Girgensohn wrote:
> Come to think of it, I guess a battery-backed cache will make fsync as fast
> as no fsync, right? So, the q was kinda stoopid... :-/
With fsync off, the data might never get to the battery-backed RAM. :-(
--
Bruce Momjian| http://candle.pha
Not in general. Besides, with a write-back cache an fsync() is very nearly
'free', as the controller will report the write as completed as soon as it's
written to cache.
I keep meaning to benchmark the difference, but I only have the facility on
a production box, so caution gets the better of me
Come to think of it, I guess a battery-backed cache will make fsync as fast
as no fsync, right? So, the q was kinda stoopid... :-/
/Palle
--On måndag, september 29, 2003 23.31.54 +0200 Palle Girgensohn
<[EMAIL PROTECTED]> wrote:
Stupid question, perhaps, but would a battery-backed cache make i
Stupid question, perhaps, but would a battery-backed cache make it safe to
set fsync=false in postgresql.conf?
/Palle
--On söndag, september 28, 2003 13.07.57 +0100 Matt Clark <[EMAIL PROTECTED]>
wrote:
As others have mentioned, you really ought to get battery-backed cache if
you're doing any
--On måndag, september 29, 2003 11.12.55 -0400 Christopher Browne
<[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Palle Girgensohn) writes:
Will that make a difference? From what I've seen, it does not make
much difference, but I have seen queries speed up when rewritten
explicit joins. I guess i
On 29 Sep 2003, Will LaShell wrote:
> On Mon, 2003-09-29 at 06:48, scott.marlowe wrote:
> > I've used the megaraid / LSI cards in the past and they were pretty good
> > in terms of reliability, but the last one I used was the 328 model, from 4
> > years ago or so. that one had a battery backup
Yes Josh,
L_partkey is a part of the foreign key on the Lineitem table, and it was
ok to create an index on it according to the TPC-R specs. I just created
indices on the rest of the FK columns in the TPC-R database and will
continue my evaluations.
Thanks.
Oleg
-Original Message-
From:
Oleg,
> I just checked the restrictions on the TPC-R and TPC-H schemas and it
> seems that all indexes are allowed in TPC-R and only those that index
> parts of primary or foreign keys are allowed in TPC-H.
That would be appropriate for this case though, yes? That column is part of
a foriegn k
On Mon, Sep 29, 2003 at 05:43:26PM -, [EMAIL PROTECTED] wrote:
>
> Anyone have a rough idea of the costs involved?
I did a back-of-an-envelope calculation one day and stopped when I
got to $10,000.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada
On Mon, 2003-09-29 at 06:48, scott.marlowe wrote:
> I've used the megaraid / LSI cards in the past and they were pretty good
> in terms of reliability, but the last one I used was the 328 model, from 4
> years ago or so. that one had a battery backup option for the cache, and
> could go to 128
Franco,
> Wouldn't it be the most portable solution to work with a domain?
> CREATE DOMAIN BIG_NUMBER AS BIGINT;
>
> If I use BIG_NUMBER everywhere I need it in my database, porting it to
> other database products should be easy... any SQL 92 compliant dbms
> should support domains.
This is a goo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm pretty certain that there are no TPC-certified test results for
> Postgres, because to date no organization has cared to spend the money
> needed to perform a certifiable test.
Anyone have a rough idea of the costs involved?
- --
Greg Sabino
Oops, my previous message got cut off.
Here is the end of it:
I just checked the restrictions on the TPC-R and TPC-H schemas and it
seems that all indexes are allowed in TPC-R and only those that index
parts of primary or foreign keys are allowed in TPC-H.
Thanks.
Oleg
-Original Message
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Also if you have fast disk drives, you can reduce random page cost to 2 or 1.5.
Note however that most of the people who have found smaller
random_page_cost to be helpful are in situations where most of their
data fits in RAM. Reducing the cost to
It took 10 hours to compute the query without the index on
lineitem.l_partkey.
Once I created the index on lineitem.l_partkey, it took only 32 secs to
run the same query.
After VACUUM ANALYZE it took 72 secs to run the query.
All the subsequent runs took under 3 seconds!
That's quite amazing!
On Saturday, September 27, 2003, at 10:39 PM, Yusuf W. wrote:
Now, I've got to convince my project's software
architech, that a bigint would be better than a
decimal.
Does anyone know where I could get some documentation
on how the int and decimal are implemented so I could
prove to him that ints
Palle Girgensohn wrote:
Will that make a difference? From what I've seen, it does not make much
difference, but I have seen queries speed up when rewritten explicit
joins. I guess it depends on other things, but is it really so that the
explicit joins are bad somehow? Do you have any pointers to
Palle Girgensohn wrote:
uu=# explain analyze
uu-# select lower(substr(p.last_name,1,1)) as letter, count(*)
uu-# FROM course c join group_data gd on (c.active_group_id =
gd.this_group_id)
uu-# join person p on (gd.item_text = p.userid)
uu-# join dyn_field_person dfp on (dfp.extern_it
[EMAIL PROTECTED] (Palle Girgensohn) writes:
> Will that make a difference? From what I've seen, it does not make
> much difference, but I have seen queries speed up when rewritten
> explicit joins. I guess it depends on other things, but is it really
> so that the explicit joins are bad somehow? D
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> Valid TPC-R benchmark results are on the TPC web site:
> http://www.tpc.org/tpcr/default.asp
> I do not see one for PostgreSQL.
I'm pretty certain that there are no TPC-certified test results for
Postgres, because to date no organization has cared
On Mon, 2003-09-29 at 07:35, Oleg Lebedev wrote:
> I left my TPC-R query #17 working over the weekend and it took 3988 mins
> ~ 10 hours to complete. And this is considering that I am using a TPC-R
> database created with a scale factor of 1, which corresponds to ~1 GB of
> data. I am running RedHa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Where can I find a plan-readinf tutorial?
This covers explain plans in depth:
http://www.gtsm.com/oscon2003/explain.html
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200309291123
-BEGIN PGP SIGNATURE-
Comment: http://
Wouldn't it be the most portable solution to work with a domain?
CREATE DOMAIN BIG_NUMBER AS BIGINT;
If I use BIG_NUMBER everywhere I need it in my database, porting it to other database products should be easy... any SQL 92 compliant dbms should support domains.
On Sun, 2003-09-28 at 00:06,
Oleg Lebedev wrote:
effective_cache_size = 32000 # typically 8KB each
That is 256MB. You can raise it to 350+MB if nothing else is running on the box.
Also if you have fast disk drives, you can reduce random page cost to 2 or 1.5.
I don't know how much this will make any difference to benchmark r
I left my TPC-R query #17 working over the weekend and it took 3988 mins
~ 10 hours to complete. And this is considering that I am using a TPC-R
database created with a scale factor of 1, which corresponds to ~1 GB of
data. I am running RedHat 8.0 on a dual 1 GHz processor, 512 MB RAM.
Here is an
Palle Girgensohn wrote:
Will that make a difference? From what I've seen, it does not make much
difference, but I have seen queries speed up when rewritten explicit
joins. I guess it depends on other things, but is it really so that the
explicit joins are bad somehow? Do you have any pointers to
I've used the megaraid / LSI cards in the past and they were pretty good
in terms of reliability, but the last one I used was the 328 model, from 4
years ago or so. that one had a battery backup option for the cache, and
could go to 128 Meg. We tested it with 4/16 and 128 meg ram, and it was
--On måndag, september 29, 2003 15.32.31 +0200 Gaetano Mendola
<[EMAIL PROTECTED]> wrote:
Are not absolutelly bad but sometimes that path that you choose is not
the optimal, in postgres 7.4 use the explicit join will be less
limitative for the planner.
Regards
Gaetano Mendola
Ah, OK. True! In thi
Will that make a difference? From what I've seen, it does not make much
difference, but I have seen queries speed up when rewritten explicit joins.
I guess it depends on other things, but is it really so that the explicit
joins are bad somehow? Do you have any pointers to documentation about it,
31 matches
Mail list logo
