Hey,
Anyone who followed the thread willing to list the mentioned
requirements as well as the pro's and con's of the differnent options in
the developer wiki [1]? I think this would help a lot in making a
decision and it could be a lot of help for other OSS projects
considering to switch.
I
On Thu, 2007-02-22 at 23:49 -0300, Alvaro Herrera wrote:
> 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
On Thursday 25 January 2007 12:51, Oleg Bartunov wrote:
> On Thu, 25 Jan 2007, Nikolay Samokhvalov wrote:
> > On 1/25/07, Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> >> It's should clear enough for now - dump data from old db and load into
> >> new one.
> >> But dump should be without any contrib/ts
On Wednesday 21 February 2007 21:23, Warren Turkal wrote:
> Are there any plans to move to another SCMS in the future? I am curious, I
> guess.
Speaking of which...Are there any plans to upgrade the CVS server to the
latest version?
wt
--
Warren Turkal (w00t)
---(end of
Hi,
Richard Levitte - VMS Whacker wrote:
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
marku
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Given that we already seem to have a patch implementing a complete
> solution
we do?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can h
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 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 ther
There's a fair amount of added work to be done when updating tuples.
Will it be possible to postpone some of that to the bgwriter in a later
version? I realize that sometimes you'll still want to do the work up
front, like if it means we can stay on the same page instead of going
cold...
On Tue, F
On Thu, Feb 22, 2007 at 10:32:44PM -0500, Matthew T. O'Connor wrote:
> 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?)
>
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.
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
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
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.
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
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
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
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
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
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, 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).
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
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
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
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
[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
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
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
> > > 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
> >> 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
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
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.
> > 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
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
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
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
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
> > 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
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
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
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
>> 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
> 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
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
>> 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
> > 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
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
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
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
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
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
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['...'
> 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
"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
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
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,
> > 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 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 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
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
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
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
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
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'
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
> > 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
> > > 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
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
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
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
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,
>
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
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
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
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,
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
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?
>
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
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
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
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 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
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]
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
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/
---
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
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
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,
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 "=", ",", "(",
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
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
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
> > 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
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
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
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.
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,
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 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
"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/
> > 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
1 - 100 of 109 matches
Mail list logo
