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 produce tree
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 not
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 frequency, and none of
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 this
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
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 IO
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 implementation and
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 in
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 same row.
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/Entries
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 implementation and
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
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, a DEAD
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?
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
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 every
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.
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?
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
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 =, ,, (, and ) in
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
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,
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 order in
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
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 workers to
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?
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
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
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
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's about that
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).
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 removing
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
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
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
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,
they're
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,
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.
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 decoupling physical
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. And then
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 these two
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
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,
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
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 ...
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 fiddling with
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
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's not
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 (without
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, SVN
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,
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
is
better
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's not
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['...']) is readable.
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
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
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 SVN -
Well
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 consensus
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 have to
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 FULLTEXT [
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
Teodor Sigaev wrote:
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
two
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 FULLTEXT [
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
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 working
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
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 driver.
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 gratefully received.
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 the logical
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
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 correct this problem now.
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 is a
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.
2)
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 make it be
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
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
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-byte
[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 cvs
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 questions
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
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
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,
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
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 differ from
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
(like
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
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. There are
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 comes
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.
If
1 - 100 of 109 matches
Mail list logo
