> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> So an inner indexscan for tab1 is definitely a possible plan.
>
> > Yes, that was my point, that a nested loop could easily be involved if
> > the joined table has a restriction. Is there a TODO item here?
>
> More like a "to investigate" --- I'm
At 00:45 16/10/00 -0400, Bruce Momjian wrote:
>What was the matter with the name pg_restore?
The fact that we will have a 'proper' backup/restore with the WAL changes,
and it seems more appropriate that the new utilities should be called
pg_backup & pg_restore. This leaves the 'undump' part of pg
Don't go changing yet. When Vadim has something, we can decide. I
think we may have unique commands for logging control and stuff, so
let's see how it plays out.
> At 00:45 16/10/00 -0400, Bruce Momjian wrote:
> >What was the matter with the name pg_restore?
>
> The fact that we will have a 'p
On Mon, 16 Oct 2000, Bruce Momjian wrote:
> What was the matter with the name pg_restore?
I didn't wanna be the one to ask, but I was kinda confused on that point
too ...
> > Since we may have a workable backup/restore based on WAL available in 7.1,
> > I am now wondering at the wisdom of creat
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> So an inner indexscan for tab1 is definitely a possible plan.
> Yes, that was my point, that a nested loop could easily be involved if
> the joined table has a restriction. Is there a TODO item here?
More like a "to investigate" --- I'm not sold on t
What was the matter with the name pg_restore?
>
> Since we may have a workable backup/restore based on WAL available in 7.1,
> I am now wondering at the wisdom of creating 'pg_restore', which reads the
> new pg_dump archive files. It is probably better to have pg_backup &
> pg_restore as the bac
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I realize only nested loop has this problem. Mergejoin and
> > Hashjoin actually would grab the whole table via sequential scan, so the
> > index is not involved, right?
>
> They'd grab the whole table after applying restriction clauses. An
>
Philip Warner <[EMAIL PROTECTED]> writes:
> As a result do people have any objection to changing pg_restore to
> pg_undump? Or pg_load?
Out of those two names, I'd vote for pg_load ...
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I realize only nested loop has this problem. Mergejoin and
> Hashjoin actually would grab the whole table via sequential scan, so the
> index is not involved, right?
They'd grab the whole table after applying restriction clauses. An
indexscan mig
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I think it's time to bite the bullet and put in a lookahead filter.
>> What say you?
> Hmmm. Not real excited about that for performance reasons. Other options?
It's been in there for a month. I'll bet lunch you will be unable to
measure any perfor
> You'll probably recall that the ambiguity between NOT NULL and NOT
> DEFERRABLE gave us similar problems. We were able to get around that
> by pretending NOT DEFERRABLE is an independent clause and leaving some
> of the parsing work to be done by analyze.c, but I don't think that
> trick will w
Since we may have a workable backup/restore based on WAL available in 7.1,
I am now wondering at the wisdom of creating 'pg_restore', which reads the
new pg_dump archive files. It is probably better to have pg_backup &
pg_restore as the backup/restore utilities.
As a result do people have any ob
Applied. Thanks. I always love doc patches.
[ Charset ISO-8859-1 unsupported, converting... ]
> > > Docs of the SSL stuff is coming up as soon as I get "final
> > approval" of
> > > the patch that brings SSL up to working (e.g. either applying or
> > > rejectnig :-). I have a very rough outl
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, assume tab2.col2 equals 3. I assume this would cause an index
> > scan because the executor doesn't know about the most common value,
> > right? Is it worth trying to improve that?
>
> Oh, I see: you are assuming that a nestloop join is be
going to try that, but it doesn't fix the problem where if someone from
the local machine sends to the local list, it won't go through either
... :( but, at least I can get htis fixed ...
On Sun, 15 Oct 2000, Dominic J. Eidson wrote:
> On Sun, 15 Oct 2000, The Hermit Hacker wrote:
>
> >
... should be working again. I hard coded the path so that it finds
bison, which appears to be what was killing it ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebs
On Sun, 15 Oct 2000, The Hermit Hacker wrote:
> I'm trying to get the committers mailing list to work, and the
> "break" is in sendmail, as far as I can tell. Basically, its taking
> 'locally posted messages' and not adding a domain to the back of it, so
> that majordomo sees them as:
>
>
Morning all ...
I'm trying to get the committers mailing list to work, and the
"break" is in sendmail, as far as I can tell. Basically, its taking
'locally posted messages' and not adding a domain to the back of it, so
that majordomo sees them as:
--== Error when connecting: Invalid ad
No, the committers list is a sendmail problem, should be fixed
momentarily, as I'm going to disable the strict domain checking on that
list ... I'll look at the snapshot thing tonight too, its using Peter's
new script(s), which appear to work great from the command line, but has a
problem when ru
KuroiNeko wrote:
> Inoue san,
>
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
>
> 1 create table al
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, assume tab2.col2 equals 3. I assume this would cause an index
> scan because the executor doesn't know about the most common value,
> right? Is it worth trying to improve that?
Oh, I see: you are assuming that a nestloop join is being done, an
Could you add to the TODO:
support of binary data (eg varbinary type)
I think the above is not trivial, as I think the parser choques on \00 bytes
at several levels...
I had a check on the TODO and it seems that TOAST is not planned anymore for
7.1. Is it true?
Franck Martin
Database Developm
[ Charset ISO-8859-1 unsupported, converting... ]
> Could you add to the TODO:
>
> support of binary data (eg varbinary type)
>
> I think the above is not trivial, as I think the parser choques on \00 bytes
> at several levels...
bytea type works for inserting null: 'a\\000b'.
>
> I had a c
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What I am more concerned about is a join that uses the most common
> > value. We do an index scan in that case.
>
> No, we do whichever plan looks cheapest. Again, it's all about
> statistics.
>
> Right now, eqjoinsel() is just a stub that return
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > My trial implementation using physical/logical attribute numbers
> > isn't so clean as I expected. I'm inclined to restrict my change to
> > fix the TODO
> > * ALTER TABLE A
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What I am more concerned about is a join that uses the most common
> value. We do an index scan in that case.
No, we do whichever plan looks cheapest. Again, it's all about
statistics.
Right now, eqjoinsel() is just a stub that returns a constant
sel
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> * Prevent index lookups (or index entries using partial index) on most
> common values; instead use sequential scan
> >>
> >> This behavior already exists for the most common value, and would
> >> exist for any additional values that we had
Bruce Momjian <[EMAIL PROTECTED]> writes:
* Prevent index lookups (or index entries using partial index) on most
common values; instead use sequential scan
>>
>> This behavior already exists for the most common value, and would
>> exist for any additional values that we had stats for.
> > > * Prevent index lookups (or index entries using partial index) on most
> > > common values; instead use sequential scan
> >
> > This behavior already exists for the most common value, and would
> > exist for any additional values that we had stats for. Don't see
> > why you think a sepa
> > * Prevent index lookups (or index entries using partial index) on most
> > common values; instead use sequential scan
>
> This behavior already exists for the most common value, and would
> exist for any additional values that we had stats for. Don't see
> why you think a separate TODO it
> * Prevent index lookups (or index entries using partial index) on most
> common values; instead use sequential scan
This behavior already exists for the most common value, and would
exist for any additional values that we had stats for. Don't see
why you think a separate TODO item is needed
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Thomas Lockhart <[EMAIL PROTECTED]> writes:
What is the status of partial indices?
>>
>> They've been diked out of gram.y's syntax for CREATE INDEX at least
>> since Postgres95. No way to tell who did that, why or when, AFAIK.
>> There is still an
> Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> > One of MySQL's little syntax abuses allows:
> > INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..);
>
> Actually, that's perfectly standard SQL92, just an item we haven't
> got round to supporting yet. (Until we do the fabled querytree
> r
> > 98304 22.07 5545984
> > 196608 45.60 11141120
> > 393216 92.53 22290432
> >
> > I tried probabilities from 0.67 to 0.999 and found that runtimes didn't
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > What is the status of
> > partial indices? Are they functional now, or have they been broken
> > forever (I'm not recalling)?
>
> They've been diked out of gram.y's syntax for CREATE INDEX at least
> since Postgres95. No way to tell who did that,
>> Well, hopefully WAL will be ready for alpha testing in a few
days.
>> Unfortunately at the moment I have to step side from main stream
>> to implement new file naming, the biggest todo for integration
WAL into system.
>>
>> I would really appreciate any h
> This is a known problem in 7.0.x (see mailing list archives for more
> information). Peter E has a patch for 7.1 to remove this problem.
Thanks and sorry for the hassle.
While we're on it, if there's any work going on premissions (separating
update/delete etc), I'd be glad to offer my help
On Sun, 15 Oct 2000, Bruce Momjian wrote:
> >
> > How do pronounce PostgreSQL - the final word (pun intended). Listen to
> > the wav file to know for sure how it's pronounced.
> >
> > http://www.postgresql.org/postgresql.wav
> >
> > And no, it's not my voice.
>
> Who's voice is it?
M
> On Fri, 25 Aug 2000, Chris Bitmead wrote:
>
> > The Hermit Hacker wrote:
> >
> > > Just because ppl are referring to the project by the wrong name doesn't
> > > make it right...
> >
> > Which do you prefer? To be the only one who is right, when everyone else
> > is wrong. Or to change the def
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > In my personal experience, out in the real world, people refer to it as
> > "Postgres". The QL being a mouthful, and contrary to the common practice
> > of pronouncing SQL as SEQUEL. While Marc points out that technically
> > Postgres died w
>
> How do pronounce PostgreSQL - the final word (pun intended). Listen to
> the wav file to know for sure how it's pronounced.
>
> http://www.postgresql.org/postgresql.wav
>
> And no, it's not my voice.
Who's voice is it?
--
Bruce Momjian| http://candle.ph
> BTW, you can get access to SIGMOD CDs with lots of goodies for a very low
> price (at least in 1999 it was a bargain), check out ACM membership for
> sigmod.
>
> I've been reading something about implementation of histograms, and,
> AFAIK, in practice histograms is just a cool name for no more
> Hi!
>
> About analyze.c:
> If taken out vacuum, couldn't it be completly taken out of pg? Say,
> to an external program? What's the big reason not to do that? I know that
> there is some code in analyze.c (like comparing) that uses other parts of
> pg, but that seems to be easily fixed.
>
> > > I'm leaning toward the implementation of end-biased histograms. There is
> > > an introductory reference in the IEEE Data Engineering Bulletin, september
> > > 1995 (available on microsoft research site).
> >
> > Sounds interesting. Can you give us an exact URL?
>
> http://www.research.
This is a known problem in 7.0.x (see mailing list archives for more
information). Peter E has a patch for 7.1 to remove this problem.
Stephan Szabo
[EMAIL PROTECTED]
On Sun, 15 Oct 2000, KuroiNeko wrote:
>
> Here's something I don't understand If I'm missing an obvious, please
> feel
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introdu
Here's something I don't understand If I'm missing an obvious, please
feel free to kick me in the right direction.
We're given two tables, linked with a foreign key. When insert is run on a
master table, everything is OK, when trying to insert into a detail table,
a strange query appears
On Sat, 14 Oct 2000, Vadim Mikheev wrote:
> Well, hopefully WAL will be ready for alpha testing in a few days.
> Unfortunately
> at the moment I have to step side from main stream to implement new file
> naming,
> the biggest todo for integration WAL into system.
>
> I would really appreciate any
Inoue san,
> This style of "DROP COLUMN" would change the attribute
> numbers whose positons are after the dropped column.
> Unfortunately we have no mechanism to invalidate/remove
> objects(or prepared plans) which uses such attribute numbers.
1 create table alpha( id int4, payload text );
2
> My trial implementation using physical/logical attribute numbers
> isn't so clean as I expected. I'm inclined to restrict my change to
> fix the TODO
> * ALTER TABLE ADD COLUMN to inherited table put column in wrong place
> though it would also introduce a backward compatibility.
> I could live
> -Original Message-
> From: Don Baccus [mailto:[EMAIL PROTECTED]]
>
> At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>
> >My conclusion would be that we need both:
> >1. a fast system table only solution with physical/logical column id
> >2. a tool that does the cleanup (e.g.
51 matches
Mail list logo
