> On Fri, 2002-04-19 at 08:15, Tatsuo Ishii wrote:
> > > > > > Can we enable syslog support by default for 7.3?
> > > > >
> > > > > AFAIR, we agreed to flip the default some time ago, we just didn't
> > > > > want to do it late in the 7.2 cycle. Go for it.
> > > >
> > > > I think if no one compl
On Thu, 18 Apr 2002, Michael Loftis wrote:
> mlw wrote:
>
> >The supposed advantage of a sequential read over an random read, in
> >an active multitasking system, is a myth. If you are executing one
> >query and the system is doing only that query, you may be right.
> >
> >Execute a number of que
On Thu, 18 Apr 2002, mlw wrote:
> The days when "head movement" is relevant are long over. Not a single drive
> sold today, or in the last 5 years, is a simple spindle/head system.
> The assumption that sequentially reading a file from a modern disk drive means
> that the head will move less
On Fri, 2002-04-19 at 08:15, Tatsuo Ishii wrote:
> > > > > Can we enable syslog support by default for 7.3?
> > > >
> > > > AFAIR, we agreed to flip the default some time ago, we just didn't
> > > > want to do it late in the 7.2 cycle. Go for it.
> > >
> > > I think if no one complains about the
> My experience has been that logging to syslog makes postgres much
> slower.
>
> Can anyone confirm or refute this ?
Do you use synchronous write with syslog? Try to add a dash in
/etc/syslog.conf
e.g.
instead of
local3.* /var/log/syslog.postgres
use
loc
> > > > Can we enable syslog support by default for 7.3?
> > >
> > > AFAIR, we agreed to flip the default some time ago, we just didn't
> > > want to do it late in the 7.2 cycle. Go for it.
> >
> > I think if no one complains about the lack of syslog on his machine we
> > should just remove the
On Fri, 2002-04-19 at 05:28, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > Can we enable syslog support by default for 7.3?
> >
> > AFAIR, we agreed to flip the default some time ago, we just didn't
> > want to do it late in the 7.2 cycle. Go for
> But note that this is on TODO:
>
> * Allow user to control trigger firing order
>
> That probably means that the user should have some reasonable way to
> change the name, besides fiddling with system catalogs.
An ALTER TRIGGER command? Of course, it should not allow modification of
constraint
En Thu, 18 Apr 2002 20:43:54 -0700 (PDT)
Stephan Szabo <[EMAIL PROTECTED]> escribió:
> I agree that name is better, I wasn't sure if we'd reached a consensus on
> it or if the conversation drifted away due to the fact that noone was
> looking at it at the time.
http://archives.postgresql.org/pgs
Tom Lane wrote:
>>This looks good to me. I only wonder if public should default to world
>>read and no create?
>
>
> That would be non-backwards-compatible. Since the main reason for
> having the public namespace at all is backwards compatibility of the
> out-of-the-box behavior, I think we ha
On Thu, 18 Apr 2002, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Didn't someone (Peter?) say that the mandated firing order was based on
> > creation order/time in SQL99?
>
> It does say that:
>
> The order of execution of a set of triggers is ascending by value
>
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Didn't someone (Peter?) say that the mandated firing order was based on
> creation order/time in SQL99?
It does say that:
The order of execution of a set of triggers is ascending by value
of their timestamp of creation in their descri
Tom Lane writes:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Can we enable syslog support by default for 7.3?
>
> AFAIR, we agreed to flip the default some time ago, we just didn't
> want to do it late in the 7.2 cycle. Go for it.
I think if no one complains about the lack of syslog on his m
On Thu, 18 Apr 2002, Tom Lane wrote:
> This particular test involves a table with a foreign-key reference to
> itself, ie, it's both PK and FK. What apparently is happening is that
> the two RI triggers are now being fired in a different order than
> before. While either of them would have dete
Michael Loftis wrote:
>
> Hiroshi Inoue wrote:
>
> >Tom Lane wrote:
> >
> >>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >>
> >>>I don't think this is *all* *should be* or *all
> >>>or nothing* kind of thing. If a SET variable has
> >>>its reason, it would behave in its own right.
> >>>
> >>Well,
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Can we enable syslog support by default for 7.3?
>
> AFAIR, we agreed to flip the default some time ago, we just didn't
> want to do it late in the 7.2 cycle. Go for it.
Ok. I'll work on this.
--
Tatsuo Ishii
---(end of bro
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Can we enable syslog support by default for 7.3?
AFAIR, we agreed to flip the default some time ago, we just didn't
want to do it late in the 7.2 cycle. Go for it.
regards, tom lane
---(end of broadcast)
Steffen Nielsen <[EMAIL PROTECTED]> writes:
> Can anyone tell me what wrong with the following codesnippet. I nuke the
> server when called (stored procedure)
> for (i = 1, buf[0] = 0; i <= tupdesc->natts; i++) {
> ccbin = check[i].ccbin;
Well, for one thing,
Can we enable syslog support by default for 7.3?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> > Will we be able to accomplish the equivelent of the below?
>
> I think what you're depicting is the equivalent of a schema owner
> dropping a table in his schema, right? Yes, I proposed allowing
that,
Yes, thats what I was looking for. Sorry if I missed that in the
initial proposal.
> > Ye
> That is, of course, a BSD-ism that would confuse a lot of the SysV
people...
> :)
Yup.. But it's been around quite a while and I don't know of any
horrible problems with it -- that said I've not actually tried it on
OpenBSD (different mindset) but would be surprised if it wasn't the
same.
Sur
Help!
Can anyone tell me what wrong with the following codesnippet. I nuke the
server when called (stored procedure)
... some VALID spi_exec call :-) has been done ...
TupleDesc tupdesc = SPI_tuptable->tupdesc;
TupleConstr *tupconstr = SPI_tuptable->tupdesc->constr;
ConstrCheck *check = tupco
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Will we be able to accomplish the equivelent of the below?
I think what you're depicting is the equivalent of a schema owner
dropping a table in his schema, right? Yes, I proposed allowing that,
but not granting the schema owner any other ownership righ
> Will we be able to accomplish the equivelent of the below?
>
>
> knight# ls -la
> total 3
> drwxr-xr-x 2 rbt rbt 512 Apr 18 21:53 .
> drwxr-xr-x 43 rbt rbt2048 Apr 18 21:36 ..
> -rwx-- 1 root wheel 0 Apr 18 21:53 file
>
> knight# head /etc/group
> # $FreeBSD: src/etc/gr
I was just fooling around with replacing the existing plain index on
pg_trigger.tgrelid with a unique index on (tgrelid, tgname). In theory
this should not affect anything --- the code already enforced that two
triggers on the same relation can't have the same name. The index
should merely provi
> I'm not real comfortable with this. The design I proposed is based
> fairly firmly on the Unix directory/file protection model --- which
> is assuredly not perfect, but it's survived a lot of use and is not
> known to have major flaws. You're suggesting that we should invent
Will we be able t
On Fri, 2002-04-19 at 02:24, Joe Conway wrote:
> I like this general idea and syntax. But it seems awkward to have to
> have the privilege granted twice. What about:
>
> GRANT CREATE SCHEMA [IN { database | ALL }] TO user | PUBLIC
> REVOKE CREATE SCHEMA [IN { database | ALL }] FROM use
Oliver Elphick wrote:
> On Fri, 2002-04-19 at 00:14, Tom Lane wrote:
> I think it could be both: a database owner may not want any schemas
> created by anyone else, or by some particular user; alternatively, the
> administrator may not want a particular user to create any schemas
> anywhere. Thes
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> [ how it ought to be to support hosting companies ]
I'm not real comfortable with this. The design I proposed is based
fairly firmly on the Unix directory/file protection model --- which
is assuredly not perfect, but it's survived a lot of use and is no
> > Another thing that would be needed to prevent users from creating
new
> > tables is to prevent them from creating schemas for themselves. I
am not
> > sure how to handle that --- should the right to create schemas be
treated
> > as a user property (a column of pg_shadow), or should it be
atta
On Fri, 2002-04-19 at 01:10, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> >> Another thing that would be needed to prevent users from creating new
> >> tables is to prevent them from creating schemas for themselves. I am not
> >> sure how to handle that --- should the right
Hiroshi Inoue wrote:
>Tom Lane wrote:
>
>>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>>
>>>I don't think this is *all* *should be* or *all
>>>or nothing* kind of thing. If a SET variable has
>>>its reason, it would behave in its own right.
>>>
>>Well, we could provide some kind of escape hatch t
On Fri, 2002-04-19 at 00:14, Tom Lane wrote:
> It's not quite clear what should happen if User A allows User B to create
> an object in a schema owned by A, but then revokes read access on that
> schema from B. Presumably, B can no longer access the object, even though
> he still owns it. A wou
Got some numbers now... You'll notice the Random reads are *really*
slow. The reason for htis is the particular read sizes that are ebing
used are the absolute worst-case for my particular configuration. (wiht
a 32kb or 64kb block size I generally achieve much higher performance
even on rand
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I don't think this is *all* *should be* or *all
> > or nothing* kind of thing. If a SET variable has
> > its reason, it would behave in its own right.
>
> Well, we could provide some kind of escape hatch to let the behavior
> vary
Joe Conway <[EMAIL PROTECTED]> writes:
> If user1, the owner of the schema1, creates a new table tab1, will user2
> who has "Read" privilege to schema1, be automatically granted SELECT
> privilege on tab1? Or will he be able to see that tab1 exists, but not
> select from it (continuing the an
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> We'll define two privilege bits for namespaces/schemas: "read" and
>> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
>> choices).
> I think other databases actually use GRANT CREATE.
Okay, I'm not picky about the keywords.
>
Tom Lane wrote:
> We'll define two privilege bits for namespaces/schemas: "read" and
> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
> choices). "Read" controls the ability to look up objects within
> that namespace --- it's similar to "execute" permission on directories
>
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I don't think this is *all* *should be* or *all
> or nothing* kind of thing. If a SET variable has
> its reason, it would behave in its own right.
Well, we could provide some kind of escape hatch to let the behavior
vary from one variable to the next.
Tom Lane writes:
> We'll define two privilege bits for namespaces/schemas: "read" and
> "create" (GRANT SELECT and GRANT INSERT seem like reasonable keyword
> choices). "Read" controls the ability to look up objects within
> that namespace --- it's similar to "execute" permission on directories
Tom Lane wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have updated the TODO to:
> > o Abort all or commit all SET changes made in an aborted transaction
> > I don't think our current behavior is defended by anyone.
>
> Hiroshi seems to like it ...
Probably I don't love it. Hone
"Rod Taylor" <[EMAIL PROTECTED]> writes:
>> Should the owner of a database (assume he's not a superuser) have the
>> right to drop any schema in his database, even if he doesn't own it?
>> I can see arguments either way on that one.
> Given that you've chosen to allow the owner of a schema or the
> Should the owner of a database (assume he's not a superuser) have
the
> right to drop any schema in his database, even if he doesn't own it?
> I can see arguments either way on that one.
Given that you've chosen to allow the owner of a schema or the table
to drop a table, it would be consistent
I've been thinking about exactly what to do with access privileges for
namespaces (a/k/a schemas). The SQL99 spec isn't much guidance, since
as far as I can tell it doesn't have explicit privileges for schemas
at all --- and in any case, since it identifies schemas and ownership,
the really inter
No problem with that. Good idea IMHO.
Jan
Tom Lane wrote:
> Currently, the name of the ON SELECT rule for a view is defined to be
> '_RET' || viewname
> truncated if necessary to fit in a NAME.
>
> I've just committed fixes to make rule names be per-relation instead
> of global, and
Indeed - I had a delayed post (sent from the wrong email address) which
mentioned that the cache is obviously at play here. I still find it
amazing that the file system would cache 2gb :) The numbers are
definitely correct though...they are actually the second set.
I'm running a test with a large
Currently, the name of the ON SELECT rule for a view is defined to be
'_RET' || viewname
truncated if necessary to fit in a NAME.
I've just committed fixes to make rule names be per-relation instead
of global, and it occurs to me that we could now get rid of this
convention. The select r
Andreas Scherbaum <[EMAIL PROTECTED]> writes:
> On the other hand, i copied some parts from contrib/noupdate (there'e no
> licence in the readme) and now i think, this is contributed under BSD
> licence.
> I'm sure or i'm wrong? I think, i have to change the licence.
> Who is the author of the nou
Tom Lane wrote:
>
> Andreas Scherbaum <[EMAIL PROTECTED]> writes:
> > Justin Clift wrote:
> >> Did we reach an opinion as to whether we'll include GPL'd code?
> >>
> >> My vote is to not include this code, as it just muddies the water with
> >> PostgreSQL being BSD based.
>
> > Hmm, there's enou
...
> Thanks a lot for the excellent software.
My personal view is that one might consider using the same BSD license
as PostgreSQL itself as a gesture of appreciation for the software you
are using. Contribute or not, it is your choice. But if you are
benefiting from the software (and lots of fo
Dav Coleman <[EMAIL PROTECTED]> writes:
> But basically I haven't done any ANALYZE or EXPLAIN yet because of the
> fact that the order -is- making a difference so it can't be executing
> the same query inside the database engine.
If you haven't ever done VACUUM ANALYZE then the planner is flying
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Alexandre Dulaunoy) would
write:
> On 18 Apr 2002, Doug McNaught wrote:
>
>> Alexandre Dulaunoy <[EMAIL PROTECTED]> writes:
>>
>> > first comment :
>> >
>> > * a special directory with ./contrib/gpl ?
>>
>> Doesn't really change anythi
Adrian 'Dagurashibanipal' von Bidder wrote:
>
> On Wed, 2002-04-17 at 19:43, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > OTOH, it is also important where the file is on disk. As seen from disk
> > > speed test graphs on http://www.tomshardware.com , the speed difference
>
first comment :
* a special directory with ./contrib/gpl ?
second comment :
* I don't really understand your position regarding the GNU General Public
License. The GPL is offering multiple advantages for a big project and
software like PostgreSQL. For example :
* Contribution
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> En 17 Apr 2002 22:53:32 -0600
> Manuel Sugawara <[EMAIL PROTECTED]> escribió:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > > Tatsuo Ishii wrote:
> > > > > I miss that case :-(. Here is the pached patch.
> > > > >
> > > > > Regards,
> > >
Numbers being run on a BSD box now...
FreeBSD 4.3-p27 512MB RAM 2xPiii600 Xeon ona 4 disk RAID 5 ARRAY on a
dedicated ICP Vortex card. Sorry no single drives on this box, I have
an outboard Silicon Gear Mercury on a motherboard based Adaptec
controller I can test as well. I'll post when the
I'm sorry, I realized after posting this that it went to the wrong
list, I resent it to pgsql-sql instead.
But basically I haven't done any ANALYZE or EXPLAIN yet because of the
fact that the order -is- making a difference so it can't be executing
the same query inside the database engine. Given
En 17 Apr 2002 22:53:32 -0600
Manuel Sugawara <[EMAIL PROTECTED]> escribió:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Tatsuo Ishii wrote:
> > > > I miss that case :-(. Here is the pached patch.
> > > >
> > > > Regards,
> > > > Manuel.
> > >
> > > I also suggest that cclass_init() is ca
Alexandre Dulaunoy <[EMAIL PROTECTED]> writes:
> * I don't really understand your position regarding the GNU General Public
> License. The GPL is offering multiple advantages for a big project and
> software like PostgreSQL.
Every month or two a newbie pops up and asks us why Postgres isn't
Alexandre Dulaunoy wrote:
> > Not open for discussion. See the FAQ.
>
> I love that type of respond ;-)
>
> Yes, I have read the faq. The 1.2 is not responding why the modified
> Berkeley-style BSD license was choosen. There is only a respond :"because
> is like that..."
>
> I have also re
On 18 Apr 2002, Doug McNaught wrote:
> Alexandre Dulaunoy <[EMAIL PROTECTED]> writes:
>
> > first comment :
> >
> > * a special directory with ./contrib/gpl ?
>
> Doesn't really change anything.
>
> > second comment :
> >
> > * I don't really understand your position regarding the GNU Gener
mlw <[EMAIL PROTECTED]> writes:
> My one most important experience (I've had more than one) with this
> whole topic is DMN's music database, when PostgreSQL uses the index,
> the query executes in a fraction of a second. When
> "enable_seqscan=true" PostgreSQL refuses to use the index, and the
> q
Here is a good example of why keeping old code around causes confusion.
I encourage the GIST guys to remove the stuff they don't feel they will
ever need. I know Tom may disagree. ;-)
---
Teodor Sigaev wrote:
> gistPageA
Justin Clift wrote:
> Hi Bruce,
>
> Did we reach an opinion as to whether we'll include GPL'd code?
>
> My vote is to not include this code, as it just muddies the water with
> PostgreSQL being BSD based.
Yes, our current policy is to add GPL to /contrib only when we have
little choice and the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have updated the TODO to:
> > o Abort all or commit all SET changes made in an aborted transaction
> > I don't think our current behavior is defended by anyone.
>
> Hiroshi seems to like it ...
>
> However, "commit SETs ev
mlw wrote:
> Bruce Momjian wrote:
> >
> > mlw wrote:
> > > I don't think we will agree, we have seen different behaviors, and our
> > > experiences seem to conflict. This however does not mean that either of us is
> > > in error, it just may mean that we use data with very different
> > > charact
...
> My one most important experience (I've had more than one) with this whole topic
> is DMN's music database, when PostgreSQL uses the index, the query executes in
> a fraction of a second. When "enable_seqscan=true" PostgreSQL refuses to use
> the index, and the query takes a about a minute. N
Alexandre Dulaunoy <[EMAIL PROTECTED]> writes:
> first comment :
>
> * a special directory with ./contrib/gpl ?
Doesn't really change anything.
> second comment :
>
> * I don't really understand your position regarding the GNU General Public
> License. The GPL is offering multiple advanta
first comment :
* a special directory with ./contrib/gpl ?
second comment :
* I don't really understand your position regarding the GNU General Public
License. The GPL is offering multiple advantages for a big project and
software like PostgreSQL. For example :
* Contribution b
Michael Loftis <[EMAIL PROTECTED]> writes:
> Somethings wrong with the random numbers from the sun... re-run them,
> that first sample is insane Caching looks like it's affecctign your
> results alot...
Yeah; it looks like the test case is not large enough to swamp out
caching effects on t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have updated the TODO to:
> o Abort all or commit all SET changes made in an aborted transaction
> I don't think our current behavior is defended by anyone.
Hiroshi seems to like it ...
However, "commit SETs even after an error" is most certa
Bruce Momjian wrote:
>
> mlw wrote:
> > I don't think we will agree, we have seen different behaviors, and our
> > experiences seem to conflict. This however does not mean that either of us is
> > in error, it just may mean that we use data with very different
> > characteristics.
> >
> > This th
Somethings wrong with the random numbers from the sun... re-run them,
that first sample is insane Caching looks like it's affecctign your
results alot...
Mark Pritchard wrote:
>I threw together the attached program (compiles fine with gcc 2.95.2 on
>Solaris 2.6 and egcs-2.91.66 on RedHat
Dav Coleman <[EMAIL PROTECTED]> writes:
> I have noticed that the semantically equivalent SQL queries can
> differ
> vastly in speed performance depending on the order of clauses ANDed
> together ( "WHERE cond1 AND cond2" takes forever, but "WHERE cond2
> AND cond1" comes right back).
Could we s
Finally someone writes down whats been itching at my brain for a while.
In a multi-tasking system it's always cheaper to fetch less blocks, no
matter where they are. Because, as you said, it will end up more or
less random onf a system experiencing a larger number of queries.
mlw wrote:
>Bru
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have added this to the TODO list, with a question mark. Hope this is
> > OK with everyone.
>
> > o Abort SET changes made in aborted transactions (?)
>
> Actually, I was planning to make only search_path act that way, bec
Hiroshi Inoue wrote:
> Michael Loftis wrote:
> >
> > Tom Lane wrote:
> >
> > >Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >
> > >>I have added this to the TODO list, with a question mark. Hope this is
> > >>OK with everyone.
> > >>
> > >
> > >>o Abort SET changes made in aborted trans
Jakub Ouhrabka <[EMAIL PROTECTED]> writes:
> can anyone explain me why there are different query plans for "select ...
> from ... where y!=x" and "select ... from ... where yx" for
> integers, please?
!= isn't an indexable operation. This is not the planner's fault, but
a consequence of the ind
Andreas Scherbaum <[EMAIL PROTECTED]> writes:
> Justin Clift wrote:
>> Did we reach an opinion as to whether we'll include GPL'd code?
>>
>> My vote is to not include this code, as it just muddies the water with
>> PostgreSQL being BSD based.
> Hmm, there's enough GPL'ed stuff in contrib/ ;-)
I
Tom Lane wrote:
> 2. The tag approach presumes that the query programmer is smarter
> than the planner. This might be true under ideal circumstances,
> but I have a hard time crediting that the planner looking at today's
> stats is dumber than the junior programmer who left two years ago,
> and
mlw wrote:
> I don't think we will agree, we have seen different behaviors, and our
> experiences seem to conflict. This however does not mean that either of us is
> in error, it just may mean that we use data with very different
> characteristics.
>
> This thread is kind of frustrating for me be
Using latest CVS sources with Linux 2.4 i586:
Comparing using domains versus traditional explicit field types.
Here's the control test:
test=# create table t1 (f varchar(5) not null);
CREATE
test=# insert into t1 values ('2');
INSERT 16626 1
test=# select * from t1 where f='2';
f
---
2
(1 row)
Justin Clift wrote:
>
> Hi Bruce,
>
> Did we reach an opinion as to whether we'll include GPL'd code?
>
> My vote is to not include this code, as it just muddies the water with
> PostgreSQL being BSD based.
>
> :-)
>
Hmm, there's enough GPL'ed stuff in contrib/ ;-)
--
On Wed, 2002-04-17 at 19:43, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > OTOH, it is also important where the file is on disk. As seen from disk
> > speed test graphs on http://www.tomshardware.com , the speed difference
> > of sequential reads is 1.5 to 2.5 between inner and o
Tom Lane wrote:
> By and large this argument reminds me of the "compiler versus hand-
> programmed assembler" argument. Which was pretty much a dead issue
> when I was an undergrad, more years ago than I care to admit in a
> public forum. Yes, a competent programmer who's willing to work
> hard
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > For instance: say we have two similarly performing plans, close to one another,
> > say within 20%, one plan uses an index, and one does not. It is unlikely that
> > the index plan will perform substantially worse than the non-index plan, ri
mlw <[EMAIL PROTECTED]> writes:
> should we not just allow the developer to place hints in the
> SQL, as:
> select /*+ INDEX(a_id, b_id) */ * from a, b where a.id = b.id;
<> People have suggested that sort of thing from time to time,
but I have a couple of problems with it:
1. It's unobvious
mlw <[EMAIL PROTECTED]> writes:
> For instance: say we have two similarly performing plans, close to one another,
> say within 20%, one plan uses an index, and one does not. It is unlikely that
> the index plan will perform substantially worse than the non-index plan, right?
This seems to be the
Apologies for the naff double post, but I meant to add that obviously
the figures for the solaris box are bogus after the first run...imagine
a file system cache of an entire 2gb file. I tried creating a file of
4gb on this box, but it bombed with a "file too large error".
Unfortunately, I can't r
Hello,
I am using postgresql to house chemical informatics data which consists
of
several interlinked tables with tens of thousands (maximum) of rows.
When
doing search queries against these tables (which always requires
multiple
joins) I have noticed that the semantically equivalent SQL queries
Hi Bruce,
Did we reach an opinion as to whether we'll include GPL'd code?
My vote is to not include this code, as it just muddies the water with
PostgreSQL being BSD based.
:-)
Regards and best wishes,
Justin Clift
Andreas Scherbaum wrote:
>
> Justin Clift wrote:
> >
> > Hi Bruce,
> >
> > H
hi,
can anyone explain me why there are different query plans for "select ...
from ... where y!=x" and "select ... from ... where yx" for
integers, please?
see the details below...
thanks,
kuba
db_cen7=# analyze;
ANALYZE
db_cen7=# \d ts19
Table "ts19"
Thats what I was going to propose if no-one could figure out a way of
automatically gathering system table dependencies.
It would be nice (for a minimallist db) to be able to drop a bunch of
stuff, but a number of other things would need to be done as well
(full system compression for example).
Michael Loftis wrote:
>
> Tom Lane wrote:
>
> >Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> >>I have added this to the TODO list, with a question mark. Hope this is
> >>OK with everyone.
> >>
> >
> >>o Abort SET changes made in aborted transactions (?)
> >>
> >
> >Actually, I was plan
On Wed, Apr 17, 2002 at 05:17:51PM -0400, Neil Conway wrote:
> Hi all,
>
> Here's an updated version of the experimental qCache patch I
> posted a couple days ago (which is a port of Karel Zak's 7.0
> work to CVS HEAD).
I have a question, what the Dllist and malloc()? I think it's
nothing nice
Tom Lane wrote:
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>>I have added this to the TODO list, with a question mark. Hope this is
>>OK with everyone.
>>
>
>>o Abort SET changes made in aborted transactions (?)
>>
>
>Actually, I was planning to make only search_path act that way, be
On Wed, Apr 17, 2002 at 06:05:59PM -0400, Neil Conway wrote:
> On Wed, 17 Apr 2002 14:34:45 -0700
>
> I'm not saying it's a bad idea, I just think I'd like to
> concentrate on the locally-cached plans for now and see if
> there is a need to add shared plans later.
Yes, later we can use shared m
On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote:
>
> On 04/17/2002 01:44:46 PM Michael Loftis wrote:
> > In many of the cases where it is a primary key it is also there to
> > ensure fast lookups when referenced as a foreign key. Or for joins.
>
> Don't know if the optimizer takes this into consid
On Wed, Apr 17, 2002 at 05:17:51PM -0400, Neil Conway wrote:
> Hi all,
>
> Here's an updated version of the experimental qCache patch I
> posted a couple days ago (which is a port of Karel Zak's 7.0
> work to CVS HEAD).
>
> Changes:
>
> - fix segfault in EXECUTE under some circumstances (report
On 04/17/2002 01:44:46 PM Michael Loftis wrote:
> In many of the cases where it is a primary key it is also there to
> ensure fast lookups when referenced as a foreign key. Or for joins.
Don't know if the optimizer takes this into consideration, but a query that uses a primary and/or unique ke
1 - 100 of 105 matches
Mail list logo
