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
node could be made to allow this.
--
Jim C. Nasby, Sr
to compare on multiple columns, so it is useful in many
situations where EXISTS or MIN/MAX techniques just don't work.
/digression
Maybe it's just the way my twisted mind thinks, but I generally prefer
using a JOIN when possible...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
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 index scans indicating that the tuple
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/pervasive.vcf cell: 512-569-9461
---(end of broadcast
, 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 Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
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: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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
bits.
Good point. Whichever we do will be wrong in some
if the bgwriter can be blocked by other
transactions, or if it needs to read pages not currently in shared memory.)
Or there could be a seperate daemon that isn't associated with bgwriter.
AFAIK as long as it vacuums the dirty page before bgwrite wants to write
it you'd still get the IO benefit.
--
Jim C
it, meaning that the scan approach will be significantly
*more* efficient than retail lookups.
The use case is any large 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
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: 512-231-6117
vcard: http
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://pervasive.comwork: 512-231-6117
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
---(end of broadcast
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 to be an untrusted language, but
that
still seems cleaner than putting it in the backend
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, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
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.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
, and welcome :)
Hmm... so would Tom D be the first 'legacy' in the community? :)
No sweat. My brother Fred was a Delta. That makes me a legacy. They
have to take me. It's their law. Don't worry. I'll put in a good word
for you.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
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 [EMAIL PROTECTED] being forwarded to
[EMAIL PROTECTED]
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
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
---(end of broadcast
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 PROTECTED]
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't think so. SQL92 6.12 numeric value expression quoth
/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.comwork: 512-231-6117
vcard: http://jim.nasby.net
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 intention that it produce a set
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
---(end of broadcast
this you're pretty much stuck running the complete suite.
--
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
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 broadcast)---
TIP 6
in terms of what's required to do
development or testing, even if it does overlap with docs-build needs.
From what I've seen it'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
, 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-6117
vcard: http://jim.nasby.net/pervasive.vcf cell
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.net/pervasive.vcf cell: 512-569
, 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-patches.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
was to
maintain the current behavior for compatability. Disk sorts are hugely
expensive, and anything to reduce that expense would be very welcome.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
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. The actual quote
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
it would be perfectly acceptable for us
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?
[1] http://www.postgresql.org/docs/8.1
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.html
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
substantially more 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-569-9461
---(end of broadcast
swapping in the first place.
--
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 broadcast
this, and unexpected behavior is
bad in any product.
Care to submit a documentation patch before releases are bundled (I
think on Sunday?) At least then people would be aware that work_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
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
---(end of broadcast
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 cell: 512-569
:)
That would be damn handy :)
--
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 broadcast)---
TIP
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. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231
to exceed work_mem by a very
large amount. Granted, this is a very painful problem to deal with and
will hopefully be changed at some point, but it's pretty clear as to how
this works.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
doubt Linux would survive that...
--
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 broadcast
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 http://pervasive.comwork: 512-231-6117
vcard: http
).
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.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569
/ 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: 512-569-9461
---(end of broadcast
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-569-9461
---(end
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.
--
Jim C
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
Before worrying about
a utility could we ship that will
download, build and install module foo for you.
CPAN modules, Ruby gems, 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
machine, but it should be possible for pgFoundry to dynamically
create a sh or batch script that can check what's on a machine and grab
tarballs as needed.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard
to be limited to just PHP...
--
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 broadcast
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/pervasive.vcf cell: 512-569-9461
.
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. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
to be consistent...
/nitpick
--
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 broadcast
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
---(end of broadcast
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 any benefit to improving SMP versus
single-proc coverage?
--
Jim C. Nasby, Sr. Engineering
free space but that has
costs too.
Again, similar to the cost with our MVCC.
--
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
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 when you have a good reason to do so.
--
Jim C. Nasby, Sr. Engineering Consultant
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 nothing joins
to.
There's actually an article floating around somewhere about how lazy
coders are good coders... :)
--
Jim C. Nasby, Sr. Engineering Consultant
...), none of that code
would exist.
* note that I'm not trying to rag on any of 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
, 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.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
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 queries.
--
Jim C. Nasby, Sr. Engineering
.
--
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 broadcast)---
TIP 3: Have you checked our
-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: 512-569-9461
---(end of broadcast
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.comwork: 512-231-6117
vcard: http
)---
TIP 5: don't forget to increase your free space map settings
--
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
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 result in a big win for certain types
data.
Take a look at cbk's comment; he does a great job of summing the issue
up.
--
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 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
---(end of broadcast)---
TIP
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-9461
---(end
. And
worst-case, you abstract behind a stored procedure that just has the
right queries hard-coded.
As for select-only views you'll have a hard time showing any meaningful
performance penalty.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
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 C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
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
---(end of broadcast)---
TIP 1: if posting
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.comwork: 512-231-6117
vcard
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 broadcast)---
TIP 3: Have you checked our
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.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
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.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
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
will both take longer and affect
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 the load on the machine.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
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
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://jim.nasby.net/pervasive.vcf cell: 512-569-9461
, 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
---(end
index, not just a PK. (It should still hold for any unique index,
right?)
Also, was an approach of sampling random rows within random blocks
considered? Something like:
until row sample size reached
read random block
sample x% of rows in that block randomly
done
--
Jim C. Nasby, Sr
that batch own the table.
I'd much rather see this as a grantable permission on the table. (The
same is true with truncate, btw). This way, if a DBA knew he could trust
a specific role, he could allow for these operations on a specific
table.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
happens to be hitting the table at
that time...
--
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 broadcast
an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
if you could specify that an entry in pg_hba.conf could be looked
up from /etc/hosts, but not from generic DNS. AFAIK that would eliminate
the possibility of spoofing.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
, though since the author of that list is
already doing the work to maintain it, maybe we just point people there
(which has the bonus of letting them see that there's a much larger
MySQL gotchas list...)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
be doing that if those statements are taking
more than a second or two to execute.
--
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
dramatically IMHO.
Yeah, I hadn't thought about that. I agree; if you trust some process
enough to have MVCC-affecting rights then you should be able to trust it
with full ownership rights.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Dumb question: if the ALTER is done inside a transaction, and then
reverted at the end of the transaction, does that mean that no other
transactions would have those permissions? I think
On Tue, Jan 03, 2006 at 12:08:05PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jan 03, 2006 at 11:26:51AM -0500, Tom Lane wrote:
Such an ALTER would certainly require exclusive lock on the table,
so I'm not sure that I see much use-case
On Tue, Jan 03, 2006 at 04:20:47PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
I don't think it should (which implies that EXCLUSIVE is a bad name).
Agreed, EXCLUSIVE was used to mean an _exclusive_ writer. The new words
I proposed were PRESERVE or STABLE.
This seems
that is visible to all sessions would have a
lot of use besides just ETL (the E stands for Extract, btw) operations.
One example is storing session data for a webapp; most people would
happily trade off losing that data on a database restart for the
increased performance of not logging.
--
Jim C
function
you could just edit in-place and test.
Of course having the ability to execute arbitrary plpgsql in .sql
scripts would be handy in some cases as well, though as others pointed
out there are alternatives.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
, via something like UPDATE NOWAL.
--
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 broadcast
BTW, this should also probably be moved over to -hackers...
--
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
prepared statement entry.
--
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 broadcast)---
TIP
that 10g has some brains in this regard, where it can
detect if it should store multiple plans for one prepared statement.
This is critical for them, because they'r parser/planner is much harder
on the system than ours is.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
701 - 800 of 1317 matches
Mail list logo
