g, as well as CPU, so it's a more effective
means of limiting the impact of large queries. I don't know how other
OS's handle this.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: &q
y more I/O bound than CPU bound. And unlike the
base tables, you generally don't need to read the WAL, so you don't
really need to worry about not being able to quickly scan through the
data without decompressing it.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Giv
ho just posted to -admin about a database that's
doing 340M inserts a day in 300M transactions...
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Li
would actually work in this
case; you could take a look at what b and c look like each time 'through
the loop'.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go
I is so much better than IDE (unless you
just give each drive it's own dedicated bandwidth).
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "
On Wed, Apr 06, 2005 at 06:35:10PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, Apr 06, 2005 at 06:09:37PM -0400, Tom Lane wrote:
> >> Can anyone suggest a more general rule? Do we need for example to
> >> consider whe
1:43 AM
> To: Joel Fradkin
> Cc: 'PostgreSQL Perform'
> Subject: Re: [PERFORM] Any way to speed this up?
>
> "Joel Fradkin" <[EMAIL PROTECTED]> writes:
> > random_page_cost = 1.2#4# units are one sequential page
> > fetch cost
>
>
ce you'd just
pass that back.
In fact, having such a function (estimate_rows_for_sql(text)) would
probably be very useful to functions that wanted to support returning a
rows estimate.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.
naive, but it seems like you
could just put a compression routine between the log writer and the
filesystem.
> Is this a TODO?
ISTM it's at least worth hacking something together and doing some
performance testing...
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
G
f the higher capacity drive be of
> greater benefit than the faster spindle speed of drive A?
The increased data density will help transfer speed off the platter, but
that's it. It won't help rotational latency.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give
benchmark
different RAID configurations using dbt2. I don't know if this is
something that the lab is setup for or capable of, though.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Wher
b with a bottleneck of one or two very large tables,
> the extra spindles won't help unless you break up the tables and
> glue them together with query magic. But it's still a point to
> consider.
Huh? Do you know how RAID10 works?
--
Jim C. Nasby, Database Consultant
gt; under 64KB=stupid, anything much over 128K/258K=wasteful.
>
> I am eager to find out how PG handles all this.
AFAIK PostgreSQL requests data one database page at a time (normally
8k). Of course the OS might do something different.
--
Jim C. Nasby, Database Consultant
ared drives. Of
course most people doing Oracle clustering are probably using a SAN and
not raw SCSI...
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
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.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Whe
lable. So
over time, depending on how frequently a table is vacuumed, it will
settle down to a steady-state size that is greater than it's size after
a vacuum full.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
memory
> (which, with 1500 rows, probably can).
Actually, the planner (at least in 7.4) isn't smart enough to consider
if the sort would fit in memory or not. I'm running a test right now to
see if it's actually faster to use an index in this case.
--
Jim C. Nasby, Database Cons
ECTED]>
> Frost Consulting, LLC http://www.frostconsultingllc.com/
> Phone: 650-780-7908 FAX: 650-649-1954
>
> ---(end of broadcast)-----------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgres
version 8.0, btw.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys com
On Tue, Apr 19, 2005 at 11:01:26PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Actually, the planner (at least in 7.4) isn't smart enough to consider
> > if the sort would fit in memory or not.
>
> Really? Have you read cost
No, this is a single process. And there's known issues with context
storms on Xeons, so that might be what you're seeing.
On Tue, Apr 19, 2005 at 09:37:21PM -0700, Mischa Sandberg wrote:
> Quoting Tom Lane <[EMAIL PROTECTED]>:
>
> > "Jim C. Nasby" <[EMA
No, he's using either COPY or \COPY.
On Wed, Apr 20, 2005 at 12:34:27AM -0400, Greg Stark wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > What's really odd is that neither the CPU or the disk are being
> > hammered. The box appears to be pre
could use \timing.
In any case, it's not valid to use pgadmin to time things.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Whe
making the wrong choice
here. BTW, changing random_page_cost to 3 or 4 doesn't change the plan.
On Tue, Apr 19, 2005 at 10:40:41PM -0500, Jim C. Nasby wrote:
> On Tue, Apr 19, 2005 at 11:01:26PM -0400, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
're going to only access the database single-user,
it's just not a valid test case (and by the way, this is true no matter
what database you're looking at. Multiuser access is where you uncover
your real bottlenecks.)
--
Jim C. Nasby, Database Consultant [EMAIL PROT
ld be thinking
wrong.
BTW, the column I'm indexing is a bigint with a low correlation.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: &quo
On Fri, Apr 22, 2005 at 10:08:06PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > I've run some performance tests. The actual test case is at
> > http://stats.distributed.net/~decibel/timing.sql, and the results are at
> > http:/
in that e-mail the new
> code also recycles more pages than before.
>
> Once I've finished it up I'll prepare and post a patch.
>
> --
> Dave Chapeskie
> OpenPGP Key ID: 0x3D2B6B34
>
> ---(end of broadcast)---
> TI
On Sat, Apr 23, 2005 at 01:00:40AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> Feel free to propose better cost equations.
>
> > Where would I look in code to see what's used now?
>
> All the gold is
say
> I'm surprised. :-)
>
>
> --
> Kevin Brown [EMAIL PROTECTED]
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-n
ome sysctl's can only be set in /boot/loader.conf.
hw.ata.wc=0 is an example (which you want to set on any box with IDE
drives if you want fsync to actually do what it thinks it's doing).
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy
UES(
(1,2,3),
(4,5,6),
(7,8,9)
);
I'm not sure how standard that is or if other databases support it.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go t
My recollection is that it does, but it's been a few years...
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go to
ed up hash joins?), if
there's no plans to fix them they should still be removed. If someone
ever really wanted to do something with, the code would still be in CVS.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net T
On Tue, May 10, 2005 at 02:38:41AM +1000, Neil Conway wrote:
> Jim C. Nasby wrote:
> >Having indexes that people shouldn't be using does add confusion for
> >users, and presents the opportunity for foot-shooting.
>
> Emitting a warning/notice on hash-index creation is s
On Tue, May 10, 2005 at 10:14:11AM +1000, Neil Conway wrote:
> Jim C. Nasby wrote:
> >> No, hash joins and hash indexes are unrelated.
> >I know they are now, but does that have to be the case?
>
> I mean, the algorithms are fundamentally unrelated. They share a bit of
bly you don't want to
re-write the entire index every time it looks like a different bucket
size would help.)
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go toda
On Tue, May 10, 2005 at 11:49:50AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > What's the challange to making it adaptive, comming up with an algorithm
> > that gives you the optimal bucket size (which I would think there's
>
is absolutely no problem at all.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>
> ---(end of broadcast)---
> TIP 7: don't forget to increase your free space map settings
>
--
Jim C. Nasby, Database Consultant [EMAIL
> This email message is for the use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and delete a
odes (ie: syncronous).
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: &
ven your experience, you might want to check out Bizgres.
(http://pgfoundry.org/projects/bizgres/) I'm sure your insights would be
most welcome.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Wind
, but that
alone isn't enough to explain the difference.
On Wed, May 11, 2005 at 05:59:10PM +0200, Manfred Koizar wrote:
> On Sun, 24 Apr 2005 17:01:46 -0500, "Jim C. Nasby" <[EMAIL PROTECTED]>
> wrote:
> >> >> Feel free to propose better cost equations.
>
solution livejournal have arrived at is quite
> similar in ways to the way google is set up.
Except that unlike LJ, google stays up and it's fast. Though granted, LJ
is quite a bit faster than it was 6 months ago.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Giv
On Thu, May 12, 2005 at 08:54:48PM +0200, Manfred Koizar wrote:
> On Wed, 11 May 2005 16:15:16 -0500, "Jim C. Nasby" <[EMAIL PROTECTED]>
> wrote:
> >> This is divided by the number of index columns, so the index correlation
> >> is estimated to be 0.
he should be flushed for each
run or not.
Does this sound like a good way to determine actual costs for index
scans (and hopefully other access methods in the future)? If so, what
would be a good way to implement this?
--
Jim C. Nasby, Database Consultant [EMAIL PROTECT
ecause
I don't see that we need to use explain when running queries. In fact,
it's possibly desireable that we don't, because of the overhead it
incurs. We would want to log an explain (maybe analyze) just to make
sure we knew what the optimizer was doing, but I think we shouldn'
On Fri, May 20, 2005 at 04:47:38PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Thu, May 19, 2005 at 09:31:47AM -0700, Josh Berkus wrote:
> >> can test our formula for accuracy and precision. However, such a formula
> >>
is huge and tends to swamp other factors out. As I
mentioned in my other email, my tests show explain analyze select * from
table is 5x slower than select count(*) from table.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! w
be able to see that index value were
complete, meaning that there was no reason to hit the heap for that
tuple.
I looked on the TODO but didn't see this, maybe it fell through the
cracks?
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy
his list from a few months ago
has more info.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
Fre
rebuilds all the indexes. It's basically the most expensive operation
you can perform on a table. There probably will be some increased
performance from the sort if the table is already mostly in the right
order though.
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give you
store what fields in what
tables/indexes each parameter corresponds to. When you go to execute you
look up the stats relevant to each parameter; you can then cache plans
according to the stats each parameter has. Of course caching all that is
a non-trivial amount of work, so you'd onl
scheduler is much worse).
>
> Here's the result, in transactions per second.
>
> ext3 jfs xfs
> -
> 10 Clients 55 81 68
> 100 Clients 61 100 64
> ----
BTW, it'd be interesti
00 rows) to
> speed the access and the update of those tables (considering that i will
> have few update but a lot of reading).
2 million rows is nothing unless you're on a 486 or something. As for
your other question, remember the first rule of performance tuning:
don't tune un
nore your desire to
>choose an index scan if your joining column's datatypes do not
>match
>
--
Jim C. Nasby, Database Consultant [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to
that every 5 mins in cron.
I would suggest leaving an option to have SA vacuum every n emails,
since some people may not want to mess with cron, etc. I suspect that
pg_autovacuum would be able to keep up with things pretty well, though.
--
Jim C. Nasby, Database Consultant
from perl,
> something isn't escaped correctly
I'm not sure who's responsible for DBI::Pg (Josh?), but would it make
sense to add better support for bytea to DBI::Pg? ISTM there should be a
better way of doing this than adding gobs of \'s.
--
Jim C. Nasby, Database Consulta
what I've read 4.2BSD actually took priority into account
when scheduling I/O. I don't know if this behavior is still present in
FreeBSD or the like, though. So depending on the OS, priority could play
a role in determining I/O scheduling.
--
Jim C. Nasby, Database Consultant [EM
> e.g. A table with books with fields holding a comment, table of content
> or example chapters
> or what ever else.
>
> Does anybody have an idea where I can find a database like this or does
> even have something like this?
Most benchmarks (such as dbt* and pgbench) have data ge
anttraffic.com
> >
> > ---(end of broadcast)---
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> >subscribe-nomail command to [EMAIL PROTECTED] so that your
> >message can
ngle one of these still begs the question of whether the
> changes will have a *material* impact on performance.
How many of these things are currently easy to change with a recompile?
I should be able to start testing some of these ideas in the near
future, if they only require minor cod
index on both 'completion_time'
> and 'start_time', but can't put a temporal lobe on the details.
>
>
> Mark
>
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
>
>htt
el query execution, not
swiching to a completely thread-based model.
In any case, there are other ways to enable parallelism without using
threads, such as handing actual query execution off to a set of
processes.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasi
d
range of OSes is important.
Can anyone recommend hardware as well as vendors? Feel free to reply
off-list.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Softwarehttp://pervasive.com512-569-9461
---(e
ing the SQL and doing what the author actually wanted, wouldn't a
bitmap combination of indexes work here?
Or with an index on (start_time, completion_time), start an index scan
at start_time = SOMEDATE and only include rows where completion_time <
SOMEDATE. Of course if SOMEDATE is near
ry.org/projects/pgcluster/) is a possible solution should
you need clustering/load balancing, but as I mentioned I suspect you
should be ok without it.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Softwarehttp://pervasive.com512-569-9461
er_foreighn_key* from
http://pgfoundry.org/projects/newsysviews/.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broa
ple, multi-column, partial and multi-column
> partial indices. we do not have functional indices.
>
> database has quite huge load of updates, but i thought that vacum will guard
> me from database bloat, but from what i observed it means that vacuuming of
> b-tree indices is
30)
Of course that means that now you have to do that in every statement
that uses that field, too...
SELECT username FROM badusers
ERROR
SELECT "UserName" FROM badusers
bad user
I suggest ditching the CamelCase and going with underline_seperators.
I'd also not use the bareword id,
AS $$
DECLARE
v_rows int;
BEGIN
DELETE FROM holding_table;
GET DIAGNOSTICS v_rows = ROW_COUNT;
UPDATE count_table
SET count = count + v_rows
;
END;
$$ LANGUAGE plpgsql;
Periodically (say, once a minute):
SELECT summarize()
VACUUM holding_table;
VACUUM count_table;
--
Jim C.
ove.
> Unfortunately, most of them require CapEx.
>
> Also, ITRW world such systems tend to have this as a chronic
> problem. This is not a "fix it once and it goes away forever". This
> is a part of the regular maintenance and upgrade plan(s).
And why DBA's typic
ject_type and actor_type make me suspect that your design is
de-normalized. Of course there's no way to know without more info.
FWIW, I usually use timestamptz for both created and updated fields.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http:/
On Sat, Oct 01, 2005 at 12:51:08PM -0700, Roger Hand wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of Jim C. Nasby
> > Sent: Friday, September 30, 2005 4:49 PM
> > Subject: Re: [PERFORM] [HACKERS] Query in S
Also, just because no one else has mentioned it, remember that it's very
easy to get MySQL into a mode where you have no data integrity. If
that's the case it's going to be faster than PostgreSQL (though I'm not
sure how much that affects the performance of SELECTs).
-
> it's got close to zero seek time.)
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/
from a data-model standpoint it doesn't matter which way you
go, I suggest looking at what it will take to write queries against both
versions before deciding. I tend to stay away from arrays because
they tend to be harder to query against.
--
Jim C. Nasby, Sr. Engineering Consultant
your guess is wrong
and you end up wasting memory that could have been used for something
else.
It would probably be better if you describe why you want to force this
table (or tables) into memory, so we can point you at more appropriate
solutions.
--
Jim C. Nasby, Sr. Engineering Consultant
u can
also make this function STABLE instead of VOLATILE. Likewise, if
FN_FIRMA_ISVISIBLE can't change any data, you can also make it STABLE
which would likely improve the performance of the query. But neither of
these ideas would account for the difference between function
performance and raw query
hly critical you'll probably want to
not wrap things in functions, and possibly not use views either.
Also, keep in mind that getting below 1ms doesn't automatically mean
you'll be able to scale to 1000TPS. Things will definately change when
you load the system down, so if pe
untime: 1.061 ms
(6 rows)
decibel=# select count(*) from t; count
458752
Note that that's on my nice slow laptop to boot (the count took like 10
seconds).
Just remember that ctid *is not safe outside of a transaction*!! So you can't
do something like
SELECT ctid FROM
On Tue, Oct 04, 2005 at 05:11:19PM -0400, Joe wrote:
> Hi Jim,
>
> Jim C. Nasby wrote:
> >Also, just because no one else has mentioned it, remember that it's very
> >easy to get MySQL into a mode where you have no data integrity. If
> >that's the case it
On Tue, Oct 04, 2005 at 04:15:41PM -0500, Jim C. Nasby wrote:
> >Index Cond: ((playerid)::text = '0'::text)
Also, why is playerid a text field? Comparing ints will certainly be
faster...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive So
this has actually happened? Especially
with 8.x, which isn't all that 'stupid' about how it handles buffers?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf
ndom/sequential ratios of modern discs)
True, but there is a compromise... not shuffling full tuples around when
sorting in memory. Do your sorting with pointers, then write the full
tuples out to 'tape' if needed.
Of course the other issue here is that as correlation improves it
becomes bet
xt
> some_other_info text
> seating_info text
> this text
> that text
> (the rest would stay in in the original PRODUCTIONS table)
>
>
> I am open to ANY suggestions, criticisms, mockery, etc.
>
> Thanks,
>
> Aaron
&g
; -----------(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster
>
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/
such values, though.
> >
> > /* Steinar */
> > --
> > Homepage: http://www.sesse.net/
> >
> >
> > ---(end of broadcast)---
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
>
stgreSQL. But if you
search the -hackers archives, you'll find a discussion on adding limited
heap tuple visibility information to indexes. That would allow for
partial index covering in many cases, which would probably be a huge win
for the queries the user was asking about.
--
Jim C. Nasby, S
ore everyone goes off about query parallelism and big
in-memory sorts and what-not, keep in mind I said "rule of thumb". :)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcar
perform callit('test()'::regprocedure, r);
> esp$# end;
> esp$#
> esp$# $$ language plpgsql;
> CREATE FUNCTION
>
> esp=# select test2();
>
> esp=# select * from test;
>f
>
> called
> (1 row)
>
> one word...
> w00t
>
>
d post it
here. You can try posting just an explain, but that's much less useful.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-94
on that offers similar
> functionality.
>
> Is there any way that I can access only those rows that were changed?
No. The only way you can do this is with row-level triggers. There's
also not currently any plans to allow statement-level triggers to
interact with the data that was modifie
ed to determine if some work is to be done and
> will be what we care the most for one type of operation.
Tough call. The key here is the amount of time required to do a join. It
also depends on if you need all the special words or not. Your best bet
is to try and benchmark both ways.
--
ad on the machine and cause it
> to hang up.
>
> Thanks,
> Ameet
>
> ---(end of broadcast)---
> TIP 1: if posting/reading through Usenet, please send an appropriate
>subscribe-nomail command to [EMAIL PROTEC
might see a
big gain by putting the tables on one mirror and the OS and transaction
logs on the other.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9
ozen or so
> FreeBSD boxes, I could be persuaded to go to Solaris x86 if the volume
> management really shines and Postgres performs well on it.
Have you looked at vinum? It might not qualify as a true volume manager,
but it's still pretty handy.
--
Jim C. Nasby, Sr. Engineering
T enable_seqscan = off;
>
> and then, after your query is done,
>
> SET enable_seqscan = on;
You can also turn it off inside a transaction and have it only affect
that transaction so that you can't accidentally forget to turn it back
on (which could seriously hose things up i
e planner. Here you need just send an email to this list and the
developers will at least see it, and will usually try and fix the issue.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/
ations. If you have to meet a specific response time requirement
for a query, you can't afford to have the optimizer suddenly decide that
some other plan might be faster when in fact it's much slower.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Soft
1 - 100 of 661 matches
Mail list logo
