* Andrew Snow <[EMAIL PROTECTED]> [001211 20:21] wrote:
>
> On Mon, 11 Dec 2000, Tom Lane wrote:
>
> > "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > > If there are no objections then I'm ready to add changes to 7.1.
> > > Else, I'll produce patches for 7.1 just after release and incorporate
>
On Tue, Dec 12, 2000 at 12:20:00AM -0400, The Hermit Hacker wrote:
>
> one thing I've found to get around this is for any query that doesn't
> appear to use the index properly, just do:
>
> SET ENABLE_SEQSCAN=OFF;
>
> SET ENABLE_SEQSCAN=ON;
>
> that way for those queries that do work right, ou
On Mon, 11 Dec 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > should be easily testable though, no?
>
> What makes you think that?
Alfred could volunteer to move to v7.1? *grin*
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> should be easily testable though, no?
What makes you think that?
> worst case, we pull it out afterwards ...
No, worst case is that we release a seriously broken 7.1, and don't
find out till afterwards.
There are plenty of new features on my to
one thing I've found to get around this is for any query that doesn't
appear to use the index properly, just do:
SET ENABLE_SEQSCAN=OFF;
SET ENABLE_SEQSCAN=ON;
that way for those queries that do work right, ou haven't forced it a
different route ..
On Mon, 11 Dec 2000, mlw wrote:
> Bruce Mom
mlw <[EMAIL PROTECTED]> writes:
> cdinfo=# explain select * from ztitles where artistid = 0 ;
> NOTICE: QUERY PLAN:
> Index Scan using ztitles_artistid_ndx on ztitles (cost=0.00..5915.01
> rows=3163 width=296)
> When postmaster is started without "-o -fs" I get this:
> cdinfo=# explain select
> > I'd vote for the second choice. I do not think we should be adding new
> > features now. Also, I don't know about you, but I have enough bug fix,
> > testing, and documentation work to keep me busy till January even
> > without any new features...
>
> It'd be really naughty to add it to the
Tim Perdue <[EMAIL PROTECTED]> writes:
> I thought the hackers team would be interested in knowing that SourceForge,
> as of Friday evening, is running on Postgres.
Cool!
> I'm running into some places where the query optimizer is not using the right
> indexes, and sometimes does sequential sca
On Mon, 11 Dec 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > I'd almost extend that to the point that it is probably more tested right
> > now then any other feature that has been added to v7.1 pre-beta,
> > considering my knowledge of Alfred's environment ...
>
> And
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > VACUUM of a toast table crashed immediately after the movement
> > of a tuple(and before inserting corresponding index tuples).
> > Unfortunately the movement of a tuple is directly committed in
> > already committed state but c
On Mon, 11 Dec 2000, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
>
> I'd vote for the second choice. I do not
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> I'd almost extend that to the point that it is probably more tested right
> now then any other feature that has been added to v7.1 pre-beta,
> considering my knowledge of Alfred's environment ...
And wasn't Alfred hollering yesterday about sudden in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But we just entered beta. Can't we let this slide? Seems like a nice
> feature. I can't image it delaying anything.
I can imagine it *breaking* lots of things.
We just today discovered that we didn't understand the interaction
between VACUUM and TOA
Bruce Momjian wrote:
> This is great news. As far as the optimizer, any chance of testing 7.1
> to see if it is improved. I believe it has been over 7.0.3.
I just did a test of my database that exhibits this behavior, using 7.1
from CVS.
When postmaster is started with "-o -fs" I get this:
cd
-- Start of PGP signed section.
> I thought the hackers team would be interested in knowing that SourceForge, as
> of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
> Source projects are depending on your stuff, so I hope it's going to be stable
> for us. ;-)
This is gr
> A few points in favor of including this ... first, when Vadim does do the
> storage manager rewrite for v7.2, the patch is essentially useless ... and
> second, its currently being used in production on a server that is/will
> tax it heavily, so it isn't untested ...
>
> I'd almost extend that
> One thing I would like to see, which we have built into our own,
> primitive, C++ interface, is support for binary data retrieval. For some
> applications the savings are huge.
> I haven't thought very hard about how to do this: we do it by having a
> perl script generate structures from the tab
On Mon, 11 Dec 2000, Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
>
> I'd vote for the second choice. I do not t
Tim Perdue wrote:
>
> I thought the hackers team would be interested in knowing that SourceForge, as
> of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
> Source projects are depending on your stuff, so I hope it's going to be stable
> for us. ;-)
>
> Throughout the co
I thought the hackers team would be interested in knowing that SourceForge, as
of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
Source projects are depending on your stuff, so I hope it's going to be stable
for us. ;-)
Throughout the codebase we're making good use of t
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If there are no objections then I'm ready to add changes to 7.1.
> Else, I'll produce patches for 7.1 just after release and incorporate
> changes into 7.2.
I'd vote for the second choice. I do not think we should be adding new
features now. Also,
Thanks. The other good item is that is already being used in production
use, so it seems it is pretty well tested.
>
> Go for it Vadim ... it is only a couple of days in, and I know there are
> several places I could personally use it ...
>
> On Mon, 11 Dec 2000, Bruce Momjian wrote:
>
> > >
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> VACUUM of a toast table crashed immediately after the movement
> of a tuple(and before inserting corresponding index tuples).
> Unfortunately the movement of a tuple is directly committed in
> already committed state but corresponding index tuples ar
Go for it Vadim ... it is only a couple of days in, and I know there are
several places I could personally use it ...
On Mon, 11 Dec 2000, Bruce Momjian wrote:
> > > If there are no objections then I'm ready to add changes to 7.1.
> > > Else, I'll produce patches for 7.1 just after release and
> > If there are no objections then I'm ready to add changes to 7.1.
> > Else, I'll produce patches for 7.1 just after release and incorporate
> > changes into 7.2.
> >
> > Comments?
>
> IMHO, we are in beta now and this doesn't fix a bug ... if we could make
> this available as a patch in /cont
On Mon, 11 Dec 2000, Mikheev, Vadim wrote:
> > > > If Vadim isn't sufficiently confident of it to commit it
> > > > on his own authority, I'm inclined to leave it out of 7.1.
> > > > My concern is mostly schedule. We are well into beta cycle
> > > > now and this seems like way too critical (not
> > > If Vadim isn't sufficiently confident of it to commit it
> > > on his own authority, I'm inclined to leave it out of 7.1.
> > > My concern is mostly schedule. We are well into beta cycle
> > > now and this seems like way too critical (not to say high-risk)
> > > a feature to be adding after
* The Hermit Hacker <[EMAIL PROTECTED]> [001211 14:27] wrote:
> On Mon, 11 Dec 2000, Bruce Momjian wrote:
>
> > > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > > Basically Vadim left it up to me to campaign for acceptance of this
> > > > work and he said he wouldn't have a problem bringing i
> > Ops, sorry - this case is not relevant to 7.1: WAL guarantees that
> > both pages will be updated on restart. Seems we are safe now.
>
> First,already committed state isn't a normal state at least
> without WAL. We must have access to db as less as possible in the
> state without WAL.
> AFAIK
"Mikheev, Vadim" wrote:
>
> > > If we move tuples in already committed state, a page with new
> > > tuple position goes to disk and backend crashes before page with
> > > old tuple position updated then we'll have two version of tuple
> > > after restart (new tuple with HEAP_MOVED_IN is valid and
On Mon, 11 Dec 2000, Bruce Momjian wrote:
> > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > Basically Vadim left it up to me to campaign for acceptance of this
> > > work and he said he wouldn't have a problem bringing it in as long
> > > as it was ok with the rest of the development team.
>
On Mon, 11 Dec 2000, Tom Lane wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Basically Vadim left it up to me to campaign for acceptance of this
> > work and he said he wouldn't have a problem bringing it in as long
> > as it was ok with the rest of the development team.
> > So can we
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Basically Vadim left it up to me to campaign for acceptance of this
> > work and he said he wouldn't have a problem bringing it in as long
> > as it was ok with the rest of the development team.
> > So can we get a go-ahead on this? :)
>
> If Vad
On Mon, Dec 11, 2000 at 02:09:35PM -0500, Lamar Owen wrote:
>
> I am cross-posting (via blind copy) this to -hackers since the community
> in -hackers is well-versed in system issues such as these.
Ah, _that's_ why my procmail filter missed this one! Couldn't think of
why you'd email me about RP
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Basically Vadim left it up to me to campaign for acceptance of this
> work and he said he wouldn't have a problem bringing it in as long
> as it was ok with the rest of the development team.
> So can we get a go-ahead on this? :)
If Vadim isn't suffi
Sounds good to me. [Of course, I never met a patch I didn't like, or so
they say.]
> I know you guys are pretty busy with the upcoming release but I
> was hoping for more interest in this work.
>
> With this (which needs forward porting) we're able to cut
> vacuum time down from ~10minutes to
On Mon, Dec 11, 2000 at 10:09:01AM -0800, Mikheev, Vadim wrote:
> > One thing we should look at before going with a 64-bit method is the
> > extra storage space for the larger checksum. We can clearly afford
> > an extra 32 bits for a checksum on an 8K disk page, but if Vadim is
> > envisioning c
Ok, after taking in feedback from several RPM users over the last six
months or so, I have come up with a list of possible changes to the
RPMset for PostgreSQL 7.1. I'd like comments on these changes. If
there are now comments, I'll go ahead and make the changes.
1.) Addition of a postgresq
I know you guys are pretty busy with the upcoming release but I
was hoping for more interest in this work.
With this (which needs forward porting) we're able to cut
vacuum time down from ~10minutes to under 30 seconds.
The code is a nop unless you compile with special options(MMNB)
specify the s
> It is clear in this algorithm that there is no order dependency: the
> conditions for keeping or discarding a candidate are fixed before we
> start the second pass, and do not vary depending on which other
> candidates were discarded before it.
I won't argue strongly for either solution, but ha
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If we move tuples in already committed state, a page with new
> tuple position goes to disk and backend crashes before page with
> old tuple position updated then we'll have two version of tuple
> after restart (new tuple with HEAP_MOVED_IN is valid a
> I suggest to remove the following elog from line 943 of xlog.c.
> It does not give real useful info and is repeated for each checkpoint,
> thus filling the log of an otherwise idle server.
>
> elog(LOG, "MoveOfflineLogs: skip %s",
> xlde->d_name);
>
> DEBUG: MoveOffl
Randy Jonasz wrote:
>
> I appreciate your comments and would like to respond to your concerns.
> The API I sketched in my earlier e-mail is borrowed heavily from
> Rogue Wave's dbtools.h++ library. I think it can be a very clean and
> elegant way of accessing a database.
Yes, this looks neat. A
> One thing we should look at before going with a 64-bit method is the
> extra storage space for the larger checksum. We can clearly afford
> an extra 32 bits for a checksum on an 8K disk page, but if Vadim is
> envisioning checksumming each individual XLOG record then the extra
> space is more a
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > When VACUUM for a table starts, the transaction is not
> > committed yet of cource. After *commit* VACUUM has handled
> > heap/index tuples very carefully to be crash-safe before
> > 7.1. Currently another vacuum could be invoked in the
> > already c
> > If we move tuples in already committed state, a page with new
> > tuple position goes to disk and backend crashes before page with
> > old tuple position updated then we'll have two version of tuple
> > after restart (new tuple with HEAP_MOVED_IN is valid and there is
> > no HEAP_MOVED_OFF in
On Sun, Dec 10, 2000 at 02:36:38PM -0500, Tom Lane wrote:
> > MD4 would be a better choice than MD5, despite that a theoretical attack
> > on MD4 has been described (albeit never executed). We don't even care
> > about real attacks, never mind theoretical ones. What matters is that
> > MD4 is
Thomas Lockhart writes:
> There is nothing stopping Marc from running the docs generation
> explicitly just before release. The group permissions in my docs build
> area are set to allow this.
That's kind of what I meant, only instead of "Marc running the docs
generation explicitly just before r
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> When VACUUM for a table starts, the transaction is not
> committed yet of cource. After *commit* VACUUM has handled
> heap/index tuples very carefully to be crash-safe before
> 7.1. Currently another vacuum could be invoked in the
> already committed tra
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Also, what happens if the specified length is less than zero? Error,
>> or is it treated as zero?
> Returns NULL in both if length <= 0. I would see the < 0 case as proper,
> but the == 0 case sure looks weird to me.
Since Oracle fails to di
I suggest to remove the following elog from line 943 of xlog.c.
It does not give real useful info and is repeated for each checkpoint,
thus filling the log of an otherwise idle server.
elog(LOG, "MoveOfflineLogs: skip %s", xlde->d_name);
DEBUG: MoveOfflineLogs: skip 000
> Interesting. I was under the impression that virtually no RISC CPU had
> a rotate instruction. Do any others?
(fyi; doesn't really contribute to the thread :/
Most or all do. There are no "pure RISC" chips in production; all have
had some optimized complex operations added for performance an
> All in all it's a synchronization and communication problem, but it's a
> real problem, as history shows.
There is nothing stopping Marc from running the docs generation
explicitly just before release. The group permissions in my docs build
area are set to allow this.
Also, since the hardcopy
> > The cons side of processes model is not the startup time. It is about
> > kernel resource and context-switch cost. Processes consume much more
> > kernel resource than threads, and have a much higher cost for context
> > switch. The scalability of threads model is much better than that of
> >
> This brings up a good point. Threads are mostly useful when you have
> multiple processes that need to share lots of data, and the interprocess
> overhead is excessive. Because we already have that shared memory area,
> this benefit of threads doesn't buy us much. We sort of already have
>
PG should include support for SHA1 anyway. MD5 is not being used in
new stuff anymore, I think. I actually have an SHA1 implementation
that links into PG if anyone is interested (especially if it could get
included in a future release).
e
> >> Perhaps they *should* truncate if the specified length is less than
> >> the original string length. Does Oracle do that?
>
> > Yes, it truncates, same as Informix.
>
> I went to fix this and then realized I still don't have an adequate spec
> of how Oracle defines these functions. It wo
On Mon, 11 Dec 2000, Thomas Lockhart wrote:
> > All in all it's a synchronization and communication problem, but it's a
> > real problem, as history shows.
>
> There is nothing stopping Marc from running the docs generation
> explicitly just before release. The group permissions in my docs build
Sorry, but I just found out that many of my mails bounced because I was using
my secondary email address =8-0
-- Forwarded Message --
Subject: Re: [HACKERS] CRC, hash & Co.
Date: Mon, 11 Dec 2000 07:13:31 +1100
From: Horst Herb <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
On Sun
59 matches
Mail list logo
