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,
--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
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
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 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
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
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,
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
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
[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
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
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
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
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!
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
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
-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
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
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
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
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
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:
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
--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
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
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
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
\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
-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://
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
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
31 matches
Mail list logo
