On Sat, 14 Oct 2000, Bruce Momjian wrote:
> > On Mon, 21 Aug 2000, Tom Lane wrote:
> >
> > > > One thing it might be interesting (please tell me if you think
> > > > otherwise) would be to improve pg with better statistical information, by
> > > > using, for example, histograms.
> > >
> > > Y
> Hi!
>
> On Wed, 23 Aug 2000, Tom Lane wrote:
>
> > Yes, we know about that one. We have stats about the most common value
> > in a column, but no information about how the less-common values are
> > distributed. We definitely need stats about several top values not just
> > one, because this
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> This is an interesting idea. We don't allow ORDER BY in
>> INSERT INTO ...
>> SELECT because it doesn't make any sense, but it does make sense if
>> LIMIT is used:
> An "order by" also makes sense if you want to create a presorted table
> fo
> On Mon, 21 Aug 2000, Tom Lane wrote:
>
> > > One thing it might be interesting (please tell me if you think
> > > otherwise) would be to improve pg with better statistical information, by
> > > using, for example, histograms.
> >
> > Yes, that's been on the todo list for a while.
>
> If i
> =?iso-8859-1?Q?Tiago_Ant=E3o?= <[EMAIL PROTECTED]> writes:
> > One thing it might be interesting (please tell me if you think
> > otherwise) would be to improve pg with better statistical information, by
> > using, for example, histograms.
>
> Yes, that's been on the todo list for a while.
>
> On Fri, Oct 13, 2000 at 10:54:31PM -0400, Bruce Momjian wrote:
> >
> > Man, Tom, our cover is working perfectly. Let's disagree on something
> > again. That will really convince them. :-)
> >
>
> This was supposed to go to -core, right? (I see Bruce got my joke. I
> wasn't so sure Tom did
On Fri, Oct 13, 2000 at 10:54:31PM -0400, Bruce Momjian wrote:
>
> Man, Tom, our cover is working perfectly. Let's disagree on something
> again. That will really convince them. :-)
>
This was supposed to go to -core, right? (I see Bruce got my joke. I
wasn't so sure Tom did ...)
Ross
--
O
Philip Warner <[EMAIL PROTECTED]> writes:
> When someone devotes hours of time to PGSQL for no recompense, their
> motives are generally not questioned. So when someone makes a design
> decision, the motive is assumed to be because it is best in the long term
> for the project. As soon as someone
> > I think ideally our role is one of cat herders, as you put it ---
> > making the kinds of decisions that a group of dozens or hundreds
> > can't make effectively. But the long-term direction of the project
> > is largely determined by what the individual CVS committers choose to
> > work on.
Philip Warner <[EMAIL PROTECTED]> writes:
>> or we need to discuss something that would embarrass someone if it
>> were publically known.
> Personal opinions are of course private. Can you think of an example of a
> secret embarrassing item that has affected the direction of the project?
> I'd be
On Fri, 13 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > okay, but, again based on my impression of what Tom has stated, and
> > previous conversations on this topic, the key problem is what happens if I
> > drop a column and a later date decide add a new column of
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> okay, but, again based on my impression of what Tom has stated, and
> previous conversations on this topic, the key problem is what happens if I
> drop a column and a later date decide add a new column of the same name,
> what happens?
I'm not very
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This said, I think Hiroshi's patch seems a perfect starting point, no ?
> Having phantom columns adds additional complexity to the system overall.
> We have to decide we really want it before making things more complex
> than they already are.
I think
On Fri, 13 Oct 2000, Zeugswetter Andreas SB wrote:
>
> > Hiroshi's patch would make for a good starting point by bringing in the
> > ability to do the DROP COLUMN feature, as I understand, without the
> > rollback capability,
>
> No Hiroshi's patch is rollback enabled, simply because all it doe
On Fri, Oct 13, 2000 at 04:10:48PM -0400, Bruce Momjian wrote:
>
> We were talking about this today down here at Great Bridge, and I
> mentioned that there is very little that happens in the core group. Up
> until Great Bridge arrived, and we had to secretly communicate with
> them, there really
> What to do? Make as much communication as possible public. When in doubt,
> err on the public side. Develop in the fish bowl. If you feel there still
> a need for private channels, perhaps include some outside representative,
> trusted by the community, who can serve as a witness of record, if y
On Wed, Oct 11, 2000 at 02:40:47PM -0400, Bruce Momjian wrote:
> > On Wed, 11 Oct 2000, Bruce Momjian wrote:
> >
> > > Considering no one has used it in 4 years that I remember, my guess is
> > > that it is an abandonded Berkeley project.
> >
> > If it does not break anything in our build proces
Dan Moschuk writes:
> Running postgres in -d 2 mode is a little frustrating on a server that
> processes as little as 10 queries a second. Can we not add getpid() or
> something to that code so that we might track which output belongs to
> which server a little easier?
If you're running 7.1-to
On Tue, Oct 10, 2000 at 01:02:52PM -0400, Tom Lane wrote:
>
> Bottom line is we're not sure what to do now. Opinions from the
> floor, anyone?
>
First, I include my voice with those congratulating Bruce, and wishing
him the best of luck in his new position.
I concur that no one who has paid
I'm trying to track down a source of great slowdown on our database, and
I seem to have become stuck.
If I issue the command...
c2net=> UPDATE url SET last_hit = 971456105 WHERE memid = 1;
This is all I see of it in my -d 2 window log.
query: UPDATE url SET last_hit = 971456105 WHERE memid =
With how we do things right now, does it actually gain us anything
to have a presorted table? Do we know not to do a seek on an index scan
if we're already at the right location in the heap file? We can't assume
the table is sorted (unless it hasn't been modified), so it's not like we
can seque
Running postgres in -d 2 mode is a little frustrating on a server that
processes as little as 10 queries a second. Can we not add getpid() or
something to that code so that we might track which output belongs to
which server a little easier?
Thanks,
-Dan
--
Man is a rational animal who alway
Tom Lane wrote:
>
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > 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. vacuum)
>
> But the peak space usage during cleanup must still b
> > > > The project name on SourceForge is "Python Interface to PostgreSQL".
> > >
> > > How about PIPgSQL or piPgSQL?
> >
> > Perhaps Pi2PgSQL, or PySQL_ba
> or PyPgSQL?
> Do we get a reward if you choose our name? ;)
No...but if this thread doesn't die soon, Marc will have to create a new
mai
> Hiroshi's patch would make for a good starting point by bringing in the
> ability to do the DROP COLUMN feature, as I understand, without the
> rollback capability,
No Hiroshi's patch is rollback enabled, simply because all it does is change
some system tables. It only does not free space tha
On Fri, 13 Oct 2000, Bruce Momjian wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > we bite the bullet to the extent of supporting a distinction between
> > > physical and logical column numbers, then ISTM there's no strong need
> > > to do any of this other stuff at all. I'd exp
On Thu, 12 Oct 2000, Mikheev, Vadim wrote:
> > > Could this be added? I am willing to help with the coding.
> >
> > This is what Version 7.1 WAL is all about.
> > There might be some help wanted in one of the possible backup methods:
> > 1. a pg_dumpall restore, and a subsequent restore of
[ Charset ISO-8859-1 unsupported, converting... ]
> > we bite the bullet to the extent of supporting a distinction between
> > physical and logical column numbers, then ISTM there's no strong need
> > to do any of this other stuff at all. I'd expect that an inserted or
> > updated tuple would hav
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > > > He does ask a legitimate question though. If you are
> > going to have a
> > > > LIMIT feature (which of course is not pure SQL), there
> > seems no reason
> > > > you shouldn't be able to insert the result into a table.
> > >
> > >
> we bite the bullet to the extent of supporting a distinction between
> physical and logical column numbers, then ISTM there's no strong need
> to do any of this other stuff at all. I'd expect that an inserted or
> updated tuple would have a NULL in any physical column position that
> doesn't ha
> > > He does ask a legitimate question though. If you are
> going to have a
> > > LIMIT feature (which of course is not pure SQL), there
> seems no reason
> > > you shouldn't be able to insert the result into a table.
> >
> >
>
> This is an interesting idea. We don't allow ORDER BY in
> I
> > 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. vacuum)
>
> But the peak space usage during cleanup must still be 2X.
The difference for a cleanup would be, that it does not need to
32 matches
Mail list logo
