at a sort we thought could fit in memory but
couldn't. It would also be good to start estimating which sorts should
fit in memory and which won't before we start (AFAIK the current code
assumes we'll fit in memory until it runs out).
--
Jim C. Nasby, Sr. Engineering Consultant [EM
E would cascade to the
> I/O functions but would raise an error if other dependent objects
> still exist.
TBH, I like Tom's idea in conjunction with a 'more destructive' CASCADE.
Having to change the types to shells, then drop the IO, then drop the
type seems like a 'gotcha&
ul than the way psql used to work. Don't know
about what's happening in -tip...
--
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
--
lock is
> held throughout the entire SP, not just during the execution of the
> TRUNCATE command. Shouldn't TRUNCATE be releasing the lock as soon as
> it finishes?
Nope. Locks stick around until the transaction finishes.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
have also tested that I can not perform a simple SELECT on the locked
> table while the SP is executing.
>
> Can anyone provide some insight?
>
> Thanks
>
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your f
If maintenance_work_mem is small you're likely to have poor performance
anyway; I'm suspicious that the overhead of starting a new xact would be
all that important. If you care about performance, you'll probably have
increased maintenance_work_mem anyway.
--
Jim C. Nasby, Sr. Engineer
it should be safe to do index lookups on
indexes that aren't expressions. And I believe that we could take steps
down the road to allow for index lookups on indexes that only used
functions that were known to be safe.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive S
filesystem and how it's created
(and possibly the OS as well). So arbitrarily deciding each bit is 8
pages is a bad idea. I could see allowing for a setting that determins
how many pages per bit, though, but I think we're also getting ahead of
ourselves.
--
Jim C. Nasby, Sr. Engin
't know what
> the net overhead would be, but it'd definitely impose some aggregate
> inefficiency.
What would be involved in reclaiming item pointer space? Is there any
reason it's not done today? (I know I've been bit once by this...)
--
Jim C. Nasby, Sr. Engineering Consult
g about,
perhaps stuff relating to corporate support and use of PostgreSQL.
--
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
of the heap file,
> in
> hopes that empty pages at the end can be truncated by VACUUM
>
>
> -----------
>
> Jim C. Nasby wrote:
> > On Fri, Dec 09, 2005 at 12:00:14AM +0200, Hannu Krosing wrote:
&g
LLOW EXTERNAL [THRESHOLD x] ] [ ALLOW COMPRESSION [THRESHOLD
> > x] ]
> >
> > ALLOW EXTERNAL: if a field is larger than x bytes (BLCKSZ/4 by default)
> > then it will be stored externally. May be specified along with ALLOW
> > COMPRESSION.
> >
> > ALLOW COMPRESS
is almost guaranteed to
provide benefits. Once we know what good they do we can move forward
from there with further improvements.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard:
27; and '-3 mon -8
days' both make sense, '1 mon -2 days' doesn't make nearly as much sense
in the general case. Of course this is complicated by the fact that '1
mon 20 days' doesn't necessarily equate to '2 mon -10 days'... :(
One of these days w
On Tue, Feb 28, 2006 at 11:58:44AM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Tue, Feb 28, 2006 at 01:18:14AM -0500, Greg Stark wrote:
> > > But I think the thought process went the other direction. If you have the
> > > bit
> > > intended for i
ISTS works in situations where
> you need to compare on multiple columns, so it is useful in many
> situations where EXISTS or MIN/MAX techniques just don't work.
>
Maybe it's just the way my twisted mind thinks, but I generally prefer
using a JOIN when possible...
--
Jim C. Nas
organized
table) when there was enough benefit to do so. This is actually
much easier to make happen inside a transaction for us, because we don't
need to keep visibility information around. There's probably also some
index metadata that could be done away with. Perhaps the materialize
t'd impose on every transaction.
True, but we don't need this for every transaction, only long-running
ones. And in most cases, it'd probably be safe to define 'long-running'
in terms of minutes. Presumably, a mechanism similar to
statement_timeout could be used to '
g on this myself, especially since PITR
> provides an alternate backup solution anyway (even in combination with
> other techniques), but the idea seems worth recording for others to
> discuss.
>
> Best Regards, Simon Riggs
>
>
> ---(end of b
ate about how to improve vacuum is due
largely to the fact that there are a very large number of possibilities.
I would very much like to see a decision on one to impliment as a
starting point. Ideas about some kind of dead-space-map, or a
known-clean-map have been floating around for at least
arge table that sees updates in 'hot spots'.
Anything that's based on current time is a likely candidate, since often
most activity only concerns the past few days of data.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
wants to write
it you'd still get the IO benefit.
--
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 broadca
On Mon, Feb 27, 2006 at 06:01:21PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Mon, Feb 27, 2006 at 02:17:23PM +, Simon Riggs wrote:
> >>> Possibly we could make EXPLAIN ANALYZE EXECUTE set the random-access
> >>>
n a vague preference for it to be quick.
Wouldn't an EXPLAIN ANALYZE DECLARE ... have the right information to
know if backward scan, etc was needed?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard:
able to rely
mostly on what's already in info_schema, so there would be a minimal
amount of work required on it. For that matter, if newsysviews became
part of the standard install, it could well be easier to build
info_schema on it instead of the base tables.
--
Jim C. Nasby, Sr. Engineering Co
good. Since there's a fairly large
number of views I don't know if it's worth having both pg_info and
pg_util.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasi
ting, though it would be good to test
an actual case (does dbt3 produce fields large enough to ensure that
most of them will be toasted?)
Given the variables involved, maybe it makes sense to add a GUC?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http:
r.
Any idea on how decompression time compares to IO bandwidth? In other
words, how long does it take to decompress 1MB vs read that 1MB vs read
whatever the uncompressed size is?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork:
;t in infoschema, since we probably
don't want to be adding extra stuff there.
--
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
s that
> would be too much of an official blessing too?)
>
> Pete
>
> >>> "Jim C. Nasby" <[EMAIL PROTECTED]> 02/24/06 8:04 am >>>
> Isn't this something that could be accomplished entirely within a
> function? I suppose it might have
27;t this something that could be accomplished entirely within a
function? I suppose it might have to be an untrusted language, but that
still seems cleaner than putting it in the backend. Plus, ISTM that
something like perl is more likely to have a cross-platform means of
accomplishing this.
--
server.
>
> So I just need to dump the schema from the test server without the indexes
> and restore the new schema to a new database/server and restore the dump
> from the production server to the new database/server.
>
> I hope I explain my side properly
--
Jim C. Nasby,
concept of
dependencies between the unit tests, ie: this select test depends on
insert test xyz. That would allow for running an arbitrary set of unit
tests; without this you're pretty much stuck running the complete suite.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
believe Slony will drop them for you
if you drop the node.
--
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
---(en
On Wed, Feb 22, 2006 at 04:26:27PM -0400, Marc G. Fournier wrote:
> On Wed, 22 Feb 2006, Jim C. Nasby wrote:
>
> >So, is there a formal project setup anywhere for the migration? ISTM
> >that it would be best to create a project on either gborg or pgfoundry
> >with the i
ntention that it produce a set of code/scripts/procedures that
allow for migrating projects from gborg to pgfoundry, since obviously
moving lists over is a minor portion of the effort.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive
On Wed, Feb 22, 2006 at 12:40:11PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Shouldn't this produce Infinity instead of an error?
> > postgresql=# select 5::float/0::float;
> > ERROR: division by zero
>
> No, I don
Shouldn't this produce Infinity instead of an error?
postgresql=# select 5::float/0::float;
ERROR: division by zero
postgresql=# select 5::float/'Infinity'::float;
?column?
--
0
(1 row)
postgresql=#
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTE
;t.
> Thanx in advanc.
> Regards
> Rafaqat Ali
--
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
-
t preserve the domain name and list names? It may help people
> make the jump if mailing list migration could be decoupled from the other
> changes.
Actually, it should be entirely possible to setup forwarding for
projects as they migrate, one-by-one. AFAIK mailman will handle
something like
> >someone had created some kind of unholy Frankensteinian chimera of Tom
> >Lane and Andrew Dunstan...
>
> Ack, I did too ... sorry TomD, and welcome :)
Hmm... so would Tom D be the first 'legacy' in the community? :)
"No sweat. My brother Fred was a Del
ld be exposed through system views than is currently being done.
--
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
a libpq-based app.
> .pgpass, pg_service, the environment vars, SSL behavior, maybe some
> other things belong in the "for users" part.
+1. Is there a docs TODO?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6
;s not terribly difficult to install some sort of
XSLT processor now-a-days. It's certainly less involved than installing
docbook in any case.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://j
, the numbers improved once he made
a few config tweaks that I suggested (see the email thread I posted
about a day or two ago for details).
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.n
out that one.
FWIW, here's a thread about this test:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12945.html
Part of the problem seems to be related to psql; he was able to run test
8 in about 5 seconds using pgAdmin:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12955
On Sat, Feb 11, 2006 at 07:50:22PM -0500, Tom Lane wrote:
> > On Sat, 2006-02-11 at 11:44 -0600, Jim C. Nasby wrote:
> >> But speaking of documentation, it doesn't actually say what the default
> >> is. Care update that, or should I formally submit a patch?
> >&g
On Sat, Feb 11, 2006 at 07:47:32PM +, Simon Riggs wrote:
> On Sat, 2006-02-11 at 11:44 -0600, Jim C. Nasby wrote:
> > On Sat, Feb 11, 2006 at 11:32:02AM -0600, Jim C. Nasby wrote:
> > > I think the point that Martijn was trying to make was that per our docs
> >
On Sat, Feb 11, 2006 at 11:32:02AM -0600, Jim C. Nasby wrote:
> I think the point that Martijn was trying to make was that per our docs
> it would be perfectly acceptable for us to make any cursor NO SCROLL
> implicitly if it means less work for the optimizer.
Ok, I take that back. T
ifferent story... ISTM doing so would
be very confusing for users.
Since this affects all queries with sorts I would definately be in favor
of exposing an option to change this ASAP, even if the default was to
maintain the current behavior for compatability. Disk sorts are hugely
expensive, and an
gs. I'd do a patch myself but I doubt I'll
> > have time before the release. :(
>
> I would be glad too. What's the process?
Well, find the appropriate file in doc/src/sgml, make a copy, edit the
file, generate a diff with diff -u, and email that diff/patch to
pgsql-pa
ff somehow. I'm not clear if NO SCROLL is
sufficient to do that or not.
--
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
--
k_mem is
just a suggestion to hash_aggs. I'd do a patch myself but I doubt I'll
have time before the release. :(
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.
reasonable
amount of swap and b) do a better job of monitoring memory usage so that
you don't start swapping in the first place.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://
_mem, because you could now ensure that
you wouldn't push the server into serious swapping.
Even better would be a means to set a cluster-wide memory limit, but of
course that's substantially more work.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
s. But after a few minutes the processes started
completing and exiting and everything was soon back to normal. I rather
doubt Linux would survive that...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard:
R BY, DISTINCT, and merge joins. Hash tables are used in hash
joins, hash-based aggregation, and hash-based processing of IN
subqueries.
So it says right there that it's very easy to exceed work_mem by a very
large amount. Granted, this is a very painful problem to deal with a
see a pressing need to add microseconds.
Something that's always struck me about intervals in PostgreSQL is the
how obtuse it is to generate one. Is there some reasonable way we could
add support for something like interval('7 microseconds')? Or perhaps
seconds(0.07)?
--
Jim C. Nasb
he standby up? Do you
have to kill it out of recovery mode and re-start, forcing it to replay
WAL again anyway?
> And #2 would be running read-only queries while in recovery :)
That would be damn handy :)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software h
not sure of the best place to put it. I could
certainly post it somewhere on pervasive-postgres.com if nothing else...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf
ed I/O.
> >
> >Yes, its designed for large data loads.
>
>
> A question - would setting fsync=off while restoring a multi-gig dump
> (during an upgrade) improve performance?
Yes.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
On Tue, Jan 31, 2006 at 03:11:50PM -0800, Jeffrey W. Baker wrote:
> On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote:
> > On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> > > Random page cost - should possible to determine this at runtime
> >
&
On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote:
> Random page cost - should possible to determine this at runtime
Before worrying about random_page_cost at all it makes a lot more sense
to look at the query cost estimates, some of which are pretty far out of
wack.
--
Ji
could probably be used here.
But I suspect adding that ability would be a pretty large amount of work
:(
--
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-5
s area would be very welcome.
http://pgfoundry.org/projects/configurator/ is something worth looking
at.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell:
ontrib and/or
pgFoundry (and prefferably could be used without a GUI).
But, OSS works by people scratching itches, so if there's folks who want
to scratch this itch...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comw
udience by doing things
like automatically including PHP as a procedure language.
And of course, there's no reason this has to be limited to just PHP...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
information in the pgFoundry database than in some other language that
pgFoundry developers are less likely to be familiar with. There would
still need to be a means to check what packages are installed on a
specific machine, but it should be possible for pgFoundry to dynamically
create a sh or batc
ms, PgFoundry ingots? :)
> >>>
> >>
> >>Tusks? (Extensions of the elephant.)
> >>
> >>
> >>
> >
> >Trunks?
>
> Dung?
I think it best to stick with the front-end of the elephant... :)
--
Jim C. Nasby, Sr. Engineeri
t we want the user to see.
Plus it can be a fairly long-running process on slower machines, so
providing feedback to the user is good.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/p
ition exists so you're aware of it. Or
maybe even refuse to run unless you supply some command line option to
over-ride.
I don't think we should morph the two together by default either,
because that's very possibly not what the user originally intended.
--
Jim C. Nasby, Sr. Engineeri
out-of-date, so perhaps there is some argument to be made for a ROLLBACK
trigger.
--
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
---
ostgres" is
> best.
Or postgresql if we want to be consistent...
--
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
--
;
> > My questions are:
> > 1) do we need another one?
> > 2) if yes, what options need coverage?
>
> Looks like we're fairly well covered on freebsd already. Are you
> willing to consider running some less-popular OS on it?
Out of curiosity, is there
On Thu, Jan 19, 2006 at 02:50:39PM -0800, Jeremy Drake wrote:
> On Thu, 19 Jan 2006, Jim C. Nasby wrote:
>
> > Do you still have that patch that folks could look at? ISTM that this
> > technique would be rather dependant on your actual workload, and as such
> > could
is there a existing command to do so?
> > >
> > > What exactly are you tryingto achieve ?
> > >
> > > -
> > > Hannu
> > >
> > >
> > >
> >
>
> ---(end of broadcast)--
bugs?
Some of the machines in the buildfarm do nothing else useful, if this
was turned into a configure option it would be trivial to setup some of
those machines to just hammer away at this.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
rmance data
The flipside is that EXPLAIN ANALYZE adds it's own (non-trivial)
overhead to the query.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell:
ain could be changed (possibly with some restrictions). IE:
CREATE DOMAIN name varchar(50); is now too small and you want to up it
to varchar(64). Granted, not supported now, though changing constraints
is currently supported.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
using index information and
> >only go back to the heap for entries that appear to pass the join test.
Do you still have that patch that folks could look at? ISTM that this
technique would be rather dependant on your actual workload, and as such
could result in a big win for certain types of
y table are only inserted
and deleted in the same transaction, which seems to be really pushing
this into corner-case territory.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim
f the numerous people who've
been involved in the stats code over the years, but it is insightful to
look at some of the 'dumb mistakes' that have been made and the large
amount of pain that it's caused.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
certain to be the table name) as a surrogate key to join on;
there's no need for me to go and figure out what does and what doesn't
have a surrogate key. The 1% that don't fall into that generally aren't
an issue because they're normally very large tables that no
e) where you want a surrogate key so
that you don't have to deal with the pain of a multiple-field key. (Note
that I don't consider simply defining a multiple-field key to be unique
as painful). So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate
27;ll be reading everything anyway.
> You also pay if the new value is too big to fit in the same space as the old
> record. Then you get to have to follow a pointer to the new location. Oracle
> tries to minimize that by intentionally leaving extra free space but that has
> costs too.
e
> query evaluation process?
SELECT count(*) FROM (SELECT ...) a;
If you're using psql \timing will probably be useful as well.
And this is better suited for -general...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comw
s less than desired
free space you move it's new version to either the next or previous
page.
--
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
-
mind this counter-argument... our MVCC
performs fewer disk writes (since generally you can find some free space
on the page you're modifying) and you can control when you take the hit
of cleaning up dead space. In fact, you can take that hit at a reduced
priority (vacuum_cost_*).
--
Jim
r:
>
> These views, in heavy querying environments, can be prohibitive.
"Normalize 'til it hurts; denormalize 'til it works."
Yes, the added overhead of rules for updates/inserts/deletes could start
to add up in performance-critical code. But if performance
od if there
was an option that allowed it. Perhaps this could be done using a
different index access method...
--
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
des to our MVCC as well; the cost of index scans
is just one.
--
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
ut on
that table. To put words in Josh's mouth, the issue isn't with using a
surrogate key, it's with not thinking about what constraints you should
be placing on your data.
Take a look at cbk's comment; he does a great job of summing the issue
up.
--
Jim C. Nasby, Sr. Engineeri
) If each parent record will have many children, the space savings from
using a surrogate key can be quite large
c) depending on how you view things, putting actual keys all over the
place is denormalized
Generally, I just use surrogate keys for everything unless performance
dictates something else
that if we know a field has to be unique, there's no
sense in doing that part of the analysis on it; you'd only care about
correlation.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.n
ve pre-reading data instead, ie, making
sure things like seqscan and bitmap scan always keep the IO system busy?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell:
On Thu, Jan 12, 2006 at 05:00:49PM -0500, Qingqing Zhou wrote:
>
>
> On Thu, 12 Jan 2006, Jim C. Nasby wrote:
>
> >
> > It sounds like worrying about this would be much more interesting on a
> > machine that is seeing both a fairly heavy IO load (meaning checkpoint
e. A simple example is doing some kind of processing once a minute
that's IO intensive with default checkpoint timing. Sometimes a
checkpoint will occur at the same time as the once-a-minute process, and
in those cases reducing the amount of work the checkpoint does will
definately help even out
effective MB/s 46.64
Reading 15% (19200/128000 blocks 1048576000 bytes) total time 23985072us
MB/s 6.56 effective MB/s 43.72
Reading 20% (25600/128000 blocks 1048576000 bytes) total time 26332888us
MB/s 7.96 effective MB/s 39.82
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
ents a counter. It
seems that any reading is actually sequential and not random, which
makes all the random_page_cost hand-waving null and void.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http:/
but reading them in heap
order, which shouldn't be anywhere near as bad as random access.
--
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
-
701 - 800 of 1353 matches
Mail list logo
