"Gavin Sherry" <[EMAIL PROTECTED]> writes:
> On Thu, 22 Feb 2007, Gregory Stark wrote:
>
>> But in a simple recursive tree search you have a node which wants to do a
>> join
>> between the output of tree level n against some table to produce tree level
>> n+1. It can't simply execute the plan to
Warren Turkal <[EMAIL PROTECTED]> writes:
> On Thursday 22 February 2007 00:42, you wrote:
>> I think you just made my point for me.
> I wasn't trying to convince so much as get an opinion.
Well, sure, it's all opinion ;-). But the overall costs of changing
SCMS are pretty enormous IMHO. We're
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Warren Turkal <[EMAIL PROTECTED]> writes:
>> On Thursday 22 February 2007 00:05, Tom Lane wrote:
>>> Not particularly. We keep hearing from various advocates that
>>> $foo-is-better-than-CVS, but the preferred value of $foo changes with
>>> amazing frequenc
Gregory Stark <[EMAIL PROTECTED]> writes:
> If we want to minimize the pain of changing and keep the same mode of
> operation Subversion is definitely the right choice. Its goal was to provide
> the same operational model as CVS and fix the implementation and architectural
> problems.
Erm ... but
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I think it would be better that leaving --with-libxml out (i.e.
compiling without libxml2 support) would only disable those parts in XML
functionality that require libxml2 for their implementation; the rest of
the stuff should be compiled in r
> vacuum should be a process with the least amount of voodoo.
> If we can just have vacuum_delay and vacuum_threshold, where
> threshold allows an arbitrary setting of how much bandwidth
> we will allot to the process, then that is a beyond wonderful thing.
>
> It is easy to determine how much
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> If we want to minimize the pain of changing and keep the same mode of
>> operation Subversion is definitely the right choice. Its goal was to provide
>> the same operational model as CVS and fix the implementatio
Nikolay Samokhvalov wrote:
> What I want to propose is just simplification -- consider all XML
> stuff as one package, including XML type, SQL/XML publishing, XPath
> funcs, additional publishing functions recently added by Peter (btw,
> who knows -- maybe libxml2 will help to improve them somehow
Gregory Stark wrote:
> [on a related note, is something wrong with my cvs rsync tree or is
> configure in the CVS repository? It's causing my patches to bloat
> considerably since I added one line to configure.in]
cat CVS/Entries
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
> > I very much like Hannu's idea, but it does present some issues.
> >
> >
> I too liked Hannu's idea initially, but Tom raised a valid
> concern that it does not address the basic issue of root
> tuples. According to the idea, a DEAD root tuple can be used
> for a subsequent update of the sam
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> [on a related note, is something wrong with my cvs rsync tree or is
>> configure in the CVS repository? It's causing my patches to bloat
>> considerably since I added one line to configure.in]
>
> cat CVS/Entries
$ cat CVS/
On Thu, 22 Feb 2007, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > If we want to minimize the pain of changing and keep the same mode of
> > operation Subversion is definitely the right choice. Its goal was to provide
> > the same operational model as CVS and fix the implementati
On Wed, 2007-02-21 at 16:57 -0300, Alvaro Herrera wrote:
> Andrew Dunstan escribió:
> > Simon Riggs wrote:
> > >
> > >I agree with comments here about the multiple orderings being a horrible
> > >source of bugs, as well as lots of coding even to make it happen at all
> > >http://archives.postgresql
On 2/22/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
> > I very much like Hannu's idea, but it does present some issues.
> >
> >
> I too liked Hannu's idea initially, but Tom raised a valid
> concern that it does not address the basic issue of root
> tuples. According to the idea,
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
If we want to minimize the pain of changing and keep the same mode of
operation Subversion is definitely the right choice. Its goal was to provide
the same operational model as CVS and fix the implementation and architectural
problems.
Hi,
Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
As we still to still discuss the syntax: is there a proposal for how a
function based syntax would look like?
CREAT
I've brought the GIT patch up-to-date with CVS head. The latest version
can be found at http://community.enterprisedb.com/git/
I also reran the CPU bound test cases with the latest patch.
I want this in 8.3 in some form, and I have the time to do any required
changes. If someone wants to see m
> > Imho we should follow the swing idea.
>
>
> Yes, thats one option. Though given a choice I would waste
> four bytes in the heap-page than inserting a new index entry.
No question about that. My point was, that it would mean wasting
the 2 (2 must be enough for a slot pointer) bytes on ever
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all the
members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed? That seems
dubious to me.
let
Markus Schiltknecht wrote:
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all
the members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed? That
On 2/22/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
>
> Yes, thats one option. Though given a choice I would waste
> four bytes in the heap-page than inserting a new index entry.
No question about that. My point was, that it would mean wasting
the 2 (2 must be enough for a slot po
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they are untypical for SQL commands. I'd
compare with CREATE FUNCTION or CREATE SEQUENCE for SQL commands that
do similar things.
I was looking at CREATE TYPE mostly. With removing "=", ",", "(",
Hi
I'm trying to gain a better understanding of how the postgres
xlog works - especially about the corner cases of wal replay.
One thing that I do not understand is what CheckPoint.undo is
used for. I grepped through the source, and only see very few
references to it, which either just print it,
CREATE FULLTEXT CONFIGURATION myfts LIKE template_cfg AS DEFAULT;
SELECT add_fulltext_config('myfts', 'template_cfg', True);
That's simple, but what about
CREATE FULLTEXT MAPPING ON cfgname FOR lexemetypename[, ...] WITH dictname1[,
...];
?
SELECT create_fulltext_mapping(cfgname, '{lexemetypena
On 2/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Right, I'm not advocating not doing that -- I'm just saying that the
>> first step to that could be decoupling physical position with attr id
>> :-) Logical column ordering (the o
What am I missing?
Seems, it's about that
http://archives.postgresql.org/pgsql-committers/2005-06/msg00085.php
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---
Hi,
[ I've CCed the monotone-devel list, as I'm sure those people are
interested, too. ]
Stefan Kaltenbrunner wrote:
Beside that - are all of the currently supported Platforms officially
supported by the proposed SCMSes ?
I can only speak for monotone. We have (had) buildbots for x86 (linux
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I missing?
Seems, it's about that
http://archives.postgresql.org/pgsql-committers/2005-06/msg00085.php
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Wed, Feb 21, 2007 at 05:40:53PM -0500, Matthew T. O'Connor wrote:
> My Proposal: If we require admins to identify hot tables tables, then:
> 1) Launcher fires-off a worker1 into database X.
> 2) worker1 deals with "hot" tables first, then regular tables.
> 3) Launcher continues to launch worke
Markus Schiltknecht wrote:
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all
the members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed? That
Jim C. Nasby wrote:
On Wed, Feb 21, 2007 at 05:40:53PM -0500, Matthew T. O'Connor wrote:
My Proposal: If we require admins to identify hot tables tables, then:
1) Launcher fires-off a worker1 into database X.
2) worker1 deals with "hot" tables first, then regular tables.
3) Launcher continu
No you're right, it's related to the WAL undo stuff that was never
actually implemented. It's dead code.
Teodor Sigaev wrote:
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I missing?
Seems, it's about that
http://archives.postgresql.org/pgsql-committers/2005-06/msg0
Heikki Linnakangas wrote:
No you're right, it's related to the WAL undo stuff that was never
actually implemented. It's dead code.
Teodor Sigaev wrote:
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I missing?
Seems, it's about that
http://archives.postgresql.org/pg
Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
> >No you're right, it's related to the WAL undo stuff that was never
> >actually implemented. It's dead code.
> >
> >Teodor Sigaev wrote:
> >>Opps, sorry, I missed checkpoint keyword
> >>
> >>Teodor Sigaev wrote:
> >>>
> What am I missing?
>
Hi,
Andrew Dunstan wrote:
CVSup is not required, and is absent from most existing clients. I don't
use it any more since the Fedora project stopped supporting it.
..which is quite understandable, concerning the PITA compiling modula-3
gives you (or at least has given me, it still hurts).
Th
Teodor Sigaev wrote:
In that proposed syntax, I would drop all "=", ",", "(", and ")".
They don't seem necessary and they are untypical for SQL commands.
I'd compare with CREATE FUNCTION or CREATE SEQUENCE for SQL commands
that do similar things.
I was looking at CREATE TYPE mostly. With re
Hi
After futher reading I fear I have to bother you with another question ;-)
There is a flag XLOG_NO_TRAN passed via the info parameter to XLogInsert.
Now, for example the following comment in clog.c
/*
* Write a TRUNCATE xlog record
*
* We must flush the xlog record to disk before returning
Florian G. Pflug wrote:
Hi
After futher reading I fear I have to bother you with another question ;-)
There is a flag XLOG_NO_TRAN passed via the info parameter to XLogInsert.
Now, for example the following comment in clog.c
/*
* Write a TRUNCATE xlog record
*
* We must flush the xlog record
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
seems to imply that (some?) wal redoe records only actually get redone
if the transaction that caused them eventually comitted. But given the
way postgres MVCC works that doesn't make sense to me, and I also can't
find any code that would actuall
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Florian G. Pflug wrote:
>> * Note: xlog record is marked as outside transaction control, since we
>> * want it to be redone whether the invoking transaction commits or not.
> That comment is a bit misleading, I agree. We don't skip xlog entries,
>
CREATE FULLTEXT CONFIGURATION myfts LIKE template_cfg AS DEFAULT;
SELECT add_fulltext_config('myfts', 'template_cfg', True);
That's simple, but what about
CREATE FULLTEXT MAPPING ON cfgname FOR lexemetypename[, ...] WITH
dictname1[, ...];
?
SELECT create_fulltext_mapping(cfgname, '{lex
Hi,
Andrew Dunstan wrote:
If we are worried about the size of the transition table and keeping it
in cache (see remarks from Tom upthread) then adding more keywords seems
a bad idea, as it will surely expand the table. OTOH, I'd hate to make
that a design criterion.
Yeah, me too. Especiall
On Thursday 22 February 2007 09:06, Phil Currier wrote:
> On 2/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > > Alvaro Herrera wrote:
> > >> Right, I'm not advocating not doing that -- I'm just saying that the
> > >> first step to that could be decoupl
> > > Yes, thats one option. Though given a choice I would waste four
> > > bytes in the heap-page than inserting a new index entry.
> >
> > No question about that. My point was, that it would mean wasting the
2
> > (2 must be enough for a slot pointer) bytes on every heap tuple, hot
> > or not
> > In any case I think it's foolish not to tackle both issues at once.
> > We know we'd like to have both features and we know that
> all the same
> > bits of code need to be looked at to implement either.
>
> I guess I disagree with that sentiment. I don't think it's
> necessary to bundle t
Hello Richard,
you should probably have read the thread on the PostgreSQL -hackers
mailing list I've linked to... at least you didn't make Tom's point ;-)
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL de
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
No you're right, it's related to the WAL undo stuff that was never
actually implemented. It's dead code.
Teodor Sigaev wrote:
Opps, sorry, I missed checkpoint keyword
Teodor Sigaev wrote:
What am I missing?
Seems, it'
Markus Schiltknecht wrote:
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL developers currently want to stay with CVS. Only some
desperate souls including myself are fiddling with other VCSes.
I really d
Hi,
Pavel Stehule wrote:
Functions maybe doesn't see efective, but user's cannot learn new syntax.
Are you serious? That argument speaks exactly *for* extending the
grammar. From other databases, users are used to:
CREATE TABLE ... (SQL)
CREATE INDEX ... (SQL)
CREATE FULLTEXT INDEX ... (Tra
Andrew Dunstan wrote:
> Markus Schiltknecht wrote:
>>
>> Richard Levitte - VMS Whacker wrote:
>>> 1. Do you want to stay with CVS or do you want to move to something
>>> else?
>>
>> Most PostgreSQL developers currently want to stay with CVS. Only some
>> desperate souls including myself are
Zeugswetter Andreas ADI SD wrote:
And I also see a lot of unhappiness from users of system tables
when column numbers all over the system tables would not be logical
column
positions any more.
Are you arguing against the feature? Or against the suggested design?
I should have thought (wi
>
> And users are constantly complaining that PostgreSQL doesn't have
> fulltext indexing capabilities (if they don't know about tsearch2) or
> about how hard it is to use tsearch2.
>
>> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> ARRAY['...']) is readable.
>
> Hardly. Becaus
On 2/22/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
I think you are still misunderstanding me, sorry if I am not beeing
clear
enough. When the row is hot-updated it is too late. You do not have room
in the root for the line pointer.
I think the word "line pointer" is causing
> > And I also see a lot of unhappiness from users of system tables when
> > column numbers all over the system tables would not be logical
column
> > positions any more.
>
> Are you arguing against the feature? Or against the suggested design?
Against the design.
> I should have thought (wit
On Thursday 22 February 2007 05:26, Andrew Dunstan wrote:
> 2. Many people (and some buildfarm members) operate against mirrors of
> the main repo which are created with rsync or CVSup. I am not aware of
> any way to do the equivalent with SVN - any info would be gratefully
> received. Of course,
Zeugswetter Andreas ADI SD wrote:
Yes, that was the idea (not oid but some number), and I am arguing
against it. Imho people are used to see the logical position in e.g.
pg_index
Which people are you talking about? In my commercial PG work I hardly
ever look at a system table at all, and
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> 2. Many people (and some buildfarm members) operate against mirrors of the
> main
> repo which are created with rsync or CVSup. I am not aware of any way to do
> the
> equivalent with SVN - any info would be gratefully received. Of course, SVN
> i
> And users are constantly complaining that PostgreSQL doesn't have
> fulltext indexing capabilities (if they don't know about tsearch2) or
> about how hard it is to use tsearch2.
>
>> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> ARRAY['...']) is readable.
>
> Hardly. Because it
Pavel Stehule wrote:
>> > And users are constantly complaining that PostgreSQL doesn't have
>> > fulltext indexing capabilities (if they don't know about tsearch2) or
>> > about how hard it is to use tsearch2.
>> >
>> >> SELECT create_fulltext_mapping(cfgname, ARRAY['lex..','..'],
>> >> ARRAY['...'
Andrew Dunstan wrote:
> It's also fair to say that this is a subject about which we usually get
> much more noise from partisans of other SCM systems than from the
> relatively small number of people who actually have to maintain the
> postgresql code. (As Tom has pointed out, our biggest pain
Warren Turkal wrote:
On Thursday 22 February 2007 05:26, Andrew Dunstan wrote:
2. Many people (and some buildfarm members) operate against mirrors of
the main repo which are created with rsync or CVSup. I am not aware of
any way to do the equivalent with SVN - any info would be gratefully
re
I am not talking about stored procedures. I am talking about a very
ugly, counter intuitive syntax above.
Initializing full text should be as simple as:
CREATE INDEX foo USING FULLTEXT(bar);
(or something similar)
Or:
CREATE TABLE foo (id serial, names text FULLTEXT);
Anything more complicat
Andrew Dunstan wrote:
> Warren Turkal wrote:
>> On Thursday 22 February 2007 05:26, Andrew Dunstan wrote:
>>
>>> 2. Many people (and some buildfarm members) operate against mirrors of
>>> the main repo which are created with rsync or CVSup. I am not aware of
>>> any way to do the equivalent with
Markus Schiltknecht wrote:
> Most PostgreSQL developers currently want to stay with CVS. Only some
> desperate souls including myself are fiddling with other VCSes.
I think if you took a head count, a majority of developers would
probably want to switch, but I doubt that there would be a consensu
> > Yes, that was the idea (not oid but some number), and I am arguing
> > against it. Imho people are used to see the logical position in e.g.
> > pg_index
> >
>
> Which people are you talking about? In my commercial PG work
> I hardly ever look at a system table at all, and users
> shouldn't
>> CREATE TABLE foo (id serial, names text FULLTEXT);
>>
>> Anything more complicated is a waste of cycles.
>>
>> Joshua D. Drake
>
> I agree. Question: what about multilanguage fulltext.
>
> CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> CREATE TABLE foo (id serial, names tex
Florian G. Pflug wrote:
> Alvaro Herrera wrote:
> >Florian G. Pflug wrote:
> >>Heikki Linnakangas wrote:
> >>>No you're right, it's related to the WAL undo stuff that was never
> >>>actually implemented. It's dead code.
> >>>
> >>>Teodor Sigaev wrote:
> Opps, sorry, I missed checkpoint keyword
> I think the word "line pointer" is causing some confusion
> here. Let me explain the idea again: Each page has a set of
> line pointers OR item-ids as they are referred in the code (I
> shall use the word item-id here after).
> The item-id stores the offset(15 bits), length (15 bits) and
> t
>> CREATE TABLE foo (id serial, names text FULLTEXT);
>>
>> Anything more complicated is a waste of cycles.
>>
>> Joshua D. Drake
>
> I agree. Question: what about multilanguage fulltext.
>
> CREATE INDEX foo USING FULLTEXT(bar) [ WITH czech_dictionary ];
> CREATE TABLE foo (id serial, names text
On Thu, 22 Feb 2007, Zeugswetter Andreas ADI SD wrote:
And I also see a lot of unhappiness from users of system tables when
column numbers all over the system tables would not be logical column
positions any more.
Right now the fact that attnum presents the logical order but not the
logi
Gregory Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
[...]
> It's also the easiest to get ahold of. Easier I would say than CVS which you
> have to download some bug fixes from various unofficial sites to get a good
> working version of.
just to mention it - the openbsd gyus are
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think you should increase pg_control version.
And the WAL page-header version, since this also changes WAL contents.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting
> > And I also see a lot of unhappiness from users of system tables when
> > column numbers all over the system tables would not be logical
column
> > positions any more.
>
> Right now the fact that attnum presents the logical order but
> not the logical position is a problem for the JDBC driv
Gregory Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > 2. Many people (and some buildfarm members) operate against mirrors of the
> > main
> > repo which are created with rsync or CVSup. I am not aware of any way to do
> > the
> > equivalent with SVN - any info would be grate
Zeugswetter Andreas ADI SD escribió:
>
> > > And I also see a lot of unhappiness from users of system tables
> > > when column numbers all over the system tables would not be
> > > logical column positions any more.
> >
> > Right now the fact that attnum presents the logical order but
> > not th
On Thu, 22 Feb 2007, Alvaro Herrera wrote:
Zeugswetter Andreas ADI SD escribió:
I agree, I haven't thought of drop column :-( Drop column should have
relabeled attnum. Since it was not done then, my comments are probably
moot.
We can correct this problem now.
How? If attnum is servin
Kris Jurka escribió:
>
>
> On Thu, 22 Feb 2007, Alvaro Herrera wrote:
>
> >Zeugswetter Andreas ADI SD escribió:
> >>
> >>I agree, I haven't thought of drop column :-( Drop column should have
> >>relabeled attnum. Since it was not done then, my comments are probably
> >>moot.
> >
> >We can corr
> > I agree, I haven't thought of drop column :-( Drop column should
have
> > relabeled attnum.
> > Since it was not done then, my comments are probably moot.
>
> We can correct this problem now.
Do you mean fix it with the 3rd column in pg_attribute and use that,
or fix attnum ? :-)
Imho it
On Thu, Feb 22, 2007 at 09:32:57AM -0500, Matthew T. O'Connor wrote:
> Jim C. Nasby wrote:
> >On Wed, Feb 21, 2007 at 05:40:53PM -0500, Matthew T. O'Connor wrote:
> >
> >>My Proposal: If we require admins to identify hot tables tables, then:
> >>1) Launcher fires-off a worker1 into database X.
On Thu, Feb 22, 2007 at 09:35:45AM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > vacuum should be a process with the least amount of voodoo.
> > If we can just have vacuum_delay and vacuum_threshold, where
> > threshold allows an arbitrary setting of how much bandwidth
> > we will allot to the
> >> I agree, I haven't thought of drop column :-( Drop column should
have
> >> relabeled attnum. Since it was not done then, my comments are
> >> probably moot.
> >
> > We can correct this problem now.
>
> How? If attnum is serving as both physical position and
> logical order, how can you m
> > > vacuum should be a process with the least amount of voodoo.
> > > If we can just have vacuum_delay and vacuum_threshold, where
> > > threshold allows an arbitrary setting of how much bandwidth we
will
> > > allot to the process, then that is a beyond wonderful thing.
> > >
> > > It is ea
On Mon, Feb 19, 2007 at 10:59:38PM -0500, Greg Smith wrote:
> I have a WIP patch that adds the main detail I have found I need to
> properly tune checkpoint and background writer activity. I think it's
> almost ready to submit (you can see the current patch against 8.2 at
> http://www.westnet.c
The numeric data type's minimum data size is 8 bytes and it can only even get
that small for "0". Storing even "1" requires 10 bytes. That seems pretty
abysmal.
It occurs to me that we could assign special-case meanings for any datum
smaller than 8 bytes. In just 2 or 4 bytes (including the 1-byt
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> Tom has pointed out, our biggest pain point is
> the occasional wish to move things across directories.
That's the biggest pain that people are normally aware of.
There are things that people don't even bother to try to do with CVS
because they are so
In message <[EMAIL PROTECTED]> on Thu, 22 Feb 2007 09:09:48 -0800, "Joshua D.
Drake" <[EMAIL PROTECTED]> said:
jd> I believe that is much more accurate. The reality is, switching to
jd> something else will be painful. I would prefer not to be on CVS as
jd> well but it would take a lot of work and
In message <[EMAIL PROTECTED]> on Thu, 22 Feb 2007 17:38:26 +0100, Markus
Schiltknecht <[EMAIL PROTECTED]> said:
markus> > So far, I'm getting the sense that there are a lot of
markus> > opinions on what replacement system to use, a bit carelessly
markus> > before having answered the above questi
If I may, I'll add a few words to this discussion:
Basically, I'm seeing that three things need to be decided upon:
1. Do you want to stay with CVS or do you want to move to something
else?
2. If you want to move, when? Is now a good time, or is it better
to look at it another time
Thanks for your answer. Is there any other risk than wrong answers when
running with wrong locale?
So maybe the best bet would be:
1) drop all text/varchar user indexes
2) stop database, change the locale
3) in single user mode reindex shared tables and system tables in all
databases and templ
On Thu, Feb 22, 2007 at 03:13:49PM +0100, Markus Schiltknecht wrote:
> one sparc (osol). So far all gcc compiled, AFAIK.
I think, that buildbot was gcc on solaris9/sparc. I care for support of
monotone built with sunpro on solaris10
(and opensolaris) on x86 and sparc (but no buildbot for those).
Column storage position is the subject of many long threads in recent
times. Solutions proposed for this have been both fairly complex and
long enough that nothing seems likely to happen for 8.3. If I'm wrong,
then of course this proposal would be superceded.
I propose that at CREATE TABLE time, t
On Thu, 2007-02-22 at 12:47 +, Heikki Linnakangas wrote:
> One question that I'm sure someone will ask is do we need this if we
> have bitmap indexes? Both aim at having a smaller index, after all.
> The use cases are quite different; GIT is effective whenever you have
> a table that's reason
Simon Riggs wrote:
>
> I propose that at CREATE TABLE time, the column ordering is re-ordered
> so that the table columns are packed more efficiently. This would be a
> physical re-ordering, so that SELECT * and COPY without explicit column
> definitions would differ from the original CREATE TABLE
Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > I propose that at CREATE TABLE time, the column ordering is re-ordered
> > so that the table columns are packed more efficiently. This would be a
> > physical re-ordering, so that SELECT * and COPY without explicit column
> > definitions would diff
On Thursday 22 February 2007 11:00, Joshua D. Drake wrote:
> 1. It has an api that can be written to, that may or may not be helpful
> to buildfarm.
>
> 2. It has mindshare. I know that isn't a big deal to a lot of people
> here, but the it is becoming the new cvs. There are others of course
> (lik
Jim C. Nasby wrote:
On Thu, Feb 22, 2007 at 09:32:57AM -0500, Matthew T. O'Connor wrote:
So the heuristic would be:
* Launcher fires off workers into a database at a given interval
(perhaps configurable?)
* Each worker works on tables in size order.
* If a worker ever catches up to an older
Warren Turkal wrote:
> On Thursday 22 February 2007 11:00, Joshua D. Drake wrote:
> > 1. It has an api that can be written to, that may or may not be helpful
> > to buildfarm.
> >
> > 2. It has mindshare. I know that isn't a big deal to a lot of people
> > here, but the it is becoming the new cvs.
Alvaro Herrera wrote:
Warren Turkal wrote:
On Thursday 22 February 2007 11:00, Joshua D. Drake wrote:
1. It has an api that can be written to, that may or may not be helpful
to buildfarm.
2. It has mindshare. I know that isn't a big deal to a lot of people
here, but the it is becoming
On Thursday 22 February 2007 20:39, Alvaro Herrera wrote:
> > Git is also pretty cool, too. You can even present a CVS interface on a
> > git repository. That might address the build farm issue.
>
> But it wasn't portable, last time I checked.
Git is in the FreeBSD ports. The cvs gateway server co
Gregory Stark <[EMAIL PROTECTED]> writes:
> [much snipped]
> Why are so few people committers?
> ...
> The answer to both questions is because CVS limitations make it hard to do
> better.
Uh, no. The reason there are so few committers is that there are so few
people qualified not to break things.
1 - 100 of 109 matches
Mail list logo
