would be possible for the database to
transparently implement this using the optimisation described.
Given that, maybe one could just add another keyword to the REFERENCES
statement that would actually do the reference with a "pointer"?
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
atements
for pretty much any non-constant input, because it's just not safe
or portable to try to escape parameters yourself.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
rameters).
> I am just pointing out that I don't think the driver
> can behind the scenes use this capability automatically.
Well, if there's little or no performance impact, I would say that
the driver should always use this capability with PreparedStatement
objects. If there
take a table off-line to work on it,
and bring it back on-line again when done? This would get rid of
the logging overhead, locking overhead, and that sort of stuff,
and in theory might be able to get you something approaching
disk-speed data imports.
cjs
--
Curt Sampson <[EMAIL PROTECTED]&
why don't we
just admit that PosgreSQL is a fairly crap performer in this regard
at the moment (at least the way I'm doing it), and work out ways
to fix this?
> Just wait until your MySQL server crashes and your client finds that half
> his data is corrupted...
If there are no
LYZE bigone;" after
> the COPY and before trying to use the table. I'm not sure if it's better to
> analyze before or after the indexes are added, but it's definitely better to
> vaccum before the indexes are added.
Thanks. This is the kind of useful information I'm
ven be extended to be
able to do foreign key checks, create indicies, and so on. (Foreign
key checks would be useful; I'm not sure that creating indicies
would be any faster than just doing it after the tablespace is
attached.)
This would be particularly useful for fast restores of backups.
he load by hand, not using
pg_restore.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 6:
e backup and
start again than to try to roll back the operation, or roll it foward
to partial completion and then figure out where to restart your import.
This seems especially likely if you can restore only the files relating
to the table that was actually damanaged.
cjs
--
Curt Sampson <[EMAI
ent is similar during random and sequential I/O on drives
in the last five years or so?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcas
nybody interested in performance is likely to have at
least 256 MB of memory, which means you're going to need a fairly large
database and a lot of workload before that becomes the problem.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.
ther, though I doubt it's changable for files still
including Berkeley source.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broa
On Fri, 19 Apr 2002, Sander Steffann wrote:
> I can't think of a reason that [creation of] temp tables should
> be prevented.
Maybe to keep hostile users from filling up your disk?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don&#x
[I've moved this discussion about changing the line pointer from four
bytes to two from -general to -hackers, since it's fairly technical.
The entire message Tom is responding to is appended to this one.]
On Sat, 20 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PR
Which would be good to get rid of, if we can.
> ...and 6 bytes for the CTID, which I guess may be unnecessary.
Really? How would things work without it?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in
ne probably doesn't want to spend a lot of time
trying to implement perfect security.
Am I siding with you or Tom here? I'm not sure. :-)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we'
On Sat, 20 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > While we're at it, would someone have the time to explain to me
> > how the on-disk CommandIds are used?
>
> To determine visibility of tuples for commands within a transactio
description
was written. Also good would be to have the data structures explicitly
named so that when one dives into the source, one already has a
good idea of what one's looking at.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you
inter array by one and make that point
to the remaining free space in the block of free space I used.
If a big enough block of free space doesn't exist, I compact the
page and try again.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don
;t do it this way.
> I don't know if there are any other places where
> a user can eat resources, but the more I think about it, the more
> complicated it gets. :-(
Yeah, exactly.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don&
ould be related only to
tuple size, and would have nothing to do with block size. Or so it seems
to me. But I have to go read the WAL code a bit before I care to make
any real assertions there.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don&
n, then there's a
> very easy root exploit..."]
That's not a downside at all. If an exploit exists, you need only
try it, and it works or it doesn't.
In fact, it's an upside becuase it allows someone who doesn't have
exploit code more easily to determine whether or
we can take a tablespace we've created this way
and attach it to an already-running postgres system, we've got
really, really fast import/export capability.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new D
ystems my return right away.
Sorry, we were working at different levels. You are thinking of
generating an I/O request on the logical level, via a system call.
I was refering to generating a physical I/O request, which a logical
I/O reqeust may or may not do.
So if you would please go back and tac
any experience to know if this is indeed the case? Has anybody
ever added this to postgresql and benchmarked it?
Certainly if there's a transaction based limit on disk I/O, as well
as a throughput limit, it would be better to read in larger chunks.
cjs
--
Curt Sampson <[EMAI
ting a storage manager that uses raw
partitions and deals with its own buffer caching? This has the potential
to be a lot more efficient, since the database server knows much more
about its workload than the operating system can guess.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 h
very little
control at all over how data is moved between memory and disk.
BTW, please don't take me as saying that all control over physical
IO should be done by Postgres. I just think that Posgres could do
a better job of managing data transfer between disk and memory than
th
ms this
happens on, and how exactly it happens.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 2:
rs, etc. more
advance information, and let them do the reads more efficiently.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 24 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Grabbing bigger chunks is always optimal, AFICT, if they're not
> > *too* big and you use the data. A single 64K read takes very little
> > longer than a single 8K read.
>
>
undertaking, and looking
> at our TODO list, I am not sure if it is worth it right now.
Right. I'm not trying to say this is a critical priority, I'm just
trying to determine what we do right now, what we could do, and
the potential performance increase that would give us.
c
On Thu, 25 Apr 2002, Curt Sampson wrote:
> Here's the ratio table again, with another column comparing the
> aggregate number of requests per second for one process and four
> processes:
>
Just for interest, I ran this again with 20 processes working
simultaneously. I did
ith BSD's FFS, there's probably not quite
as much jumping as you'd think. An FFS filesystem is divided into
"cylinder groups" (though these days the groups don't necessarially
match the physical cylinder boundaries on the disk) and a file's
i-node entry is kept in th
On Thu, 25 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > 1. Theoretical proof: two components of the delay in retrieving a
> > block from disk are the disk arm movement and the wait for the
> > right block to rotate under the head.
>
&
oesn't hold, but in the vast, vast
majority of circumstances it does.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)--
le this makes sense, it may be better to just increase
> the block size overall.
I don't think so, because the smaller block size is definitely
better for random I/O.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in
of the readahead (64K, I propose--oh wait, we
can only do 32K....)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)
ws. If it's only for people's expectations,
but we default to #1, their expectations will be violated until
they figure out that the option is there. After they figure out
it's there, well, they don't expect it to behave like Oracle any
more, so they don't need the switch, right?
c
ire quite bit of coding to make it
> work.
That's kind of too bad, since log shipping is a very popular method of
backup and replication.
Not that I'm volunteering to fix this. :-)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don'
lly shipping us in /etc/services?
NetBSD will be, as of 1.7, though the 1.7 release is a while away yet.
(Sorry, I didn't find out about this in time to get it into for 1.6,
which is just about to be released.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netb
you have any case
> studies in this regd?
It all depends entirely on the application. Really. Some applications
will work just as well on Postgres as they will on Oracle; others
will be almost impossible with Postgres.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www
|
If the write is unsuccessful, you end up with something like this:
| 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 |
And now you know which parts of your page got written, and which
parts didn't.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974
On Fri, 21 Jun 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > And now you know which parts of your page got written, and which
> > parts didn't.
>
> Yes ... and what do you *do* about it?
Ok. Here's the extract from _Inside Microsoft
t; doesn't do the writes in parallel?...
> It would seem to me that if the same process does both ping-pong writes,
> then there should be a cheap way to enforce a serial order. I could be
> wrong though.
Well, whether or not there's a cheap way depends on whether you consid
On Sun, 23 Jun 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > This should also allow us to disable completely the ping-pong writes
> > if we have a disk subsystem that we trust.
>
> If we have a disk subsystem we trust, we just disable fsync on th
tem that guarantees no
torn pages and thus will want to turn off the ping-pong file writes
entirely, anyway.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --X
s really going
to guarantee your writes (which then means you don't need it).
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadc
e note, I've been a NetBSD developer since about '96,
and have been delving into the details of OS design since well before
that time, so I'm coming to this with what I hope is reasonably good
knowledge of how disks work and how operating systems use them. (Not
that this should stop you
e basis, and there is no standard way for a program to
> discover this. Most system administrators are not going to know this
> either, unless databases are their main responsibility.
Certainly this is true of pretty much every database system out there.
cjs
--
Curt Sampson <[E
rted out, a long long time ago, on systems without
unified buffer cache and so on, and so they *had* to write this stuff
because otherwise data would not be cached. So Oracle can also afford to
maintain it now because the code already exists.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 773
> What do our cache-hit percentages look like? I'm going to do some
> experimenting with this.
Well, that depends on how much memory you have and what your working
set is. :-)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you kno
think I can address most of the concerns in doc/TODO.detail/mmap.
Is this worth pursuing a bit? (I.e., should I spend an hour or two
writing up the advantages and thoughts on how to get around the
problems?) Anybody got objections that aren't in doc/TODO.detail/mmap?
cjs
--
Curt Sampson <
x27;t
even need to "propagate," because the memory is truly shared. You'd keep
your locks in the page itself as well, of course.
Can you describe the problem in more detail?
> But as long as you stay away from interpretation #2 and go with
> mmap-as-a-shmget-substitute, it might
erver can deal with five thousand connections without even
blinking.)
> and those stupid, stupid READ locks that make many complex updates
> deadlock.
I'll admit that this is one area that I usually like much better about
postgres. Although the locking system, though harder to use, has
its ad
On Wed, 26 Jun 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Note that your proposal of using mmap to replace sysv shared memory
> > relies on the behaviour I've described too.
>
> True, but I was not envisioning mapping an actual file ---
a where there is a monumental difference is in license fees. For
> a single corporation, it does not matter.
Even for a single corporation, it can matter. Deploying, say, ten
smallish Oracle servers is not exactly cheap.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://
res doesn't.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
be just where he would be if the hack were never
implmemented in the first place.
Otherwise you only have to leave the feature in until the next major
release, anyway, right? Because for major releases it's expected that
you will have to dump and restore you database anyway, hmm?
cjs
--
Curt
On Thu, 27 Jun 2002, Tom Lane wrote:
> ...but the missing table end-tag is probably the killer:
That kills me in Netscape 4.78 all the time. It's a well known problem.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, i
a group-id + user-id table determines which users are in
which groups. In one project a couple of years ago, such a table was 85
million rows.) These types of tables are typically 8 bytes of data and
40 or so bytes of overhead. Ouch!
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974
issues well enough.
I hear this all the time, but I have yet to have someone show me what,
Iin SO-2022-JP, EUC-JP or SJIS cannot be transparently translated into
Unicode and back.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in t
explicit, not implicit action.
And as far as the compatability thing goes, well, probably pretty
much everyone agrees that it's better to break things such that
you are less likely to lose data
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
tion detail, and
> the user should only think about the constraint.
Exactly my feeling.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of br
and highly unlikley to conflict with anything.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 3: if
ce.)
I would suggest it's probably a good idea to stick to ASCII graphic
(i.e., non-control, not delete) characters.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all li
ory
> lookups. Not sure if it is worth worrying about.
Probably not such a big deal, since most systems will be reading
a full block (8K or 16K under *BSD) to load the directory information
anyway. Doing it in hex would give you only 8-char filenames, anyway.
cjs
--
Curt Sampson <[EMAIL
ate: tuple concurrently updated." Can anybody tell
me more about this error and its consequences?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
-
hat the code that updates
> system catalogs is not prepared to cope with concurrent updates
> to the same tuple.
I see. So the error is basically harmless, and can be rectified anyway
with an ANALYZE, right?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.net
On Sun, 28 Jul 2002, Tom Lane wrote:
> Other than the fact that the second CREATE INDEX fails and rolls back,
> there's no problem ;-)
Agh!
So what, in the current version of postgres, are my options for
doing parallel index builds?
cjs
--
Curt Sampson <[EMAIL PROTECTED]>
tems, and many of its failures are being addressed. Postgres for some
reason seems to attract some really, really smart people to work on it.
If I could see something better, I'd be there. But I don't.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.ne
On Mon, 29 Jul 2002, Bruce Momjian wrote:
> Curt Sampson wrote:
> > I'm still waiting to find out just what advantage table inheritance
> > offers. I've asked a couple of times here, and nobody has even started
> > to come up with anything.
>
> We inherited i
could check for the "Return-Path:" header, or maybe "From " (note:
no colon) if you're using a Berkeley-mailbox style system, and find
out the e-mail address of the real sender.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www
ropriate rules,
and he'll get exactly the same effect. And maybe that will help
fix his index problems, too)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
);
INSERT INTO test VALUES (1, 'one', 'onemore');
returns "ERROR: Cannot insert into a view without an appropriate rule"
for that last statement. The rule does show up in pg_rules, though.
What am I doing wrong here? Is there a bug?
cjs
--
Curt Sampson
me notion of named storage area, perhaps
> including the "tablespace" nomenclature
This I would really love to have.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
ot
> emulate it...
Right. I get really, really worried about security issues when I see
something like "just specify an environment variable." Who knows what
the heck else is in the environment.
I'd really like to see that removed and replaced with a configuration file
or so
On Tue, 30 Jul 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > CREATE VIEW test AS ...
> > CREATE RULE test_insert AS
> > ON INSERT TO test
> > DO ...
> > INSERT INTO test VALUES (1, 'one', 'onemore');
&
blem for others.
> > Also, some examples in the manual would be helpful.
>
> Aren't there several already? But feel free to contribute more...
Yeah, but nothing showing these rules on a view across two tables.
I'll try to work it out and send it here for comments.
cjs
--
Curt
On Wed, 31 Jul 2002, Tom Lane wrote:
> ERROR: Cannot insert into a view
> You need an unconditional ON INSERT DO INSTEAD rule
Sounds great to me!
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Da
On 29 Jul 2002, Hannu Krosing wrote:
> > > Curt Sampson wrote:
> > > > I'm still waiting to find out just what advantage table inheritance
> > > > offers. I've asked a couple of times here, and nobody has even started
> > > > to come up
e model adds complexity without adding the
ability to do things you couldn't easily do before. (This, IMHO, makes
table inheritance quite inelegant.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we&#x
where everything is, as well.)
I tend to side with you on not putting these paths in the database
itself; it can make restores rather hairy.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light.
tmaster/backend pay attention to environment
variables at all. An explicit configuration file would seem a better
answer.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
--
nheritance ?
Becuase SQL has a long, long history of doing things badly. The language
has been non-relational in many ways from the very beginning. But Codd
and Date argue that much better than I do, so I'd prefer you read their
books and respond to those arguments. I can provide references if
a bit
of a feel for what kinds of things are typically exploited. And this one
one just screams, "potential security vulnerability!" to me.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
rs and bears" out there.
Well, I'm not sure how using a config file rather than environment
variables is stopping us from proceeding
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this
ducts_data USING (product_id)
What functionality does table inheritance offer that this traditional
relational method of doing things doesn't?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're
ve
to modify in the relational way of doing things that you don't in this
inheritance way?
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of bro
On Tue, 30 Jul 2002, Bruce Momjian wrote:
> Curt Sampson wrote:
> > On Tue, 30 Jul 2002, Bruce Momjian wrote:
> >
> > > You can add children without modifying your code. It is classic C++
> > > inheritance; parent table accesses work with the new child tabl
On Tue, 30 Jul 2002, Lamar Owen wrote:
> On Tuesday 30 July 2002 07:46 pm, Curt Sampson wrote:
>
> > Ah. See, we already have a failure in a security analysis here. This
> > command:
>
> > CREATE DATABASE foo WITH LOCATION = 'BAR'
>
> > us
le are reasonably familiar
with postgres and (presumably) use it all the time, and you think
this is not a security problem?!
Anyway, I'll shut up now.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age
e if we did that.
> Of course we could go the other way and remove support for VIEW's as
> they can be done using a table and a ON SELECT DO INSTEAD rule.
> Actually this is how they are done.
*Sigh*. You seem to be unable to distinguish between changes to
the conceptual model of a
vvar" camp not yet dealt with? What's
missing in that patch posted here a while back to specify your data
files in the configuration file? (Presumably we'd just add the log file
to that in a similar way.)
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.ne
rid of (for instance) $PGPORT for clients,
> right?
I'm certainly not wanting to get rid of it on the client. I won't go
into the reasons unless anybody really cares
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don'
re yearcol=2001
You want to be careful with this sort of stuff, since the query planner
sometimes won't do the view as efficiently as it would do the fully
specified equivalant query. I've posted about this here before.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974
a need, let's make it
a separate feature from being able to specify the location in the
logfile, and implement it separately so we don't slow down the
original feature we're all looking for.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
On Thu, 1 Aug 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > You want to be careful with this sort of stuff, since the query planner
> > sometimes won't do the view as efficiently as it would do the fully
> > specified equivalant query. I&
;s always safe, or that it's safe
> under such-and-such conditions, I'll see what I can do about making it
> happen.
It's on my list of things to do, but not high enough that it's
likely I'll ever get to it. :-)
BTW, if anybody can think of a way to make a view th
On Thu, 1 Aug 2002, Zeugswetter Andreas SB SD wrote:
> I had a "union all" view, which is actually a quite different animal than
> a "union" view which needs to eliminate duplicates before further processing.
I had the same problem with UNION ALL.
cjs
--
Curt
is non-relational in many ways, so I guess they
figured making it non-relational in one more way can't hurt.
I mean come on, this is a language which started out not even
relationally complete!
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://
1 - 100 of 255 matches
Mail list logo
