Marc G. Fournier wrote:
>
>
> --On Thursday, August 16, 2007 23:16:09 +0200 Magnus Hagander
> <[EMAIL PROTECTED]> wrote:
>
>> But my question still stands - how much work to stop-gap fix it on the
>> old one?
>
> rsync should be upgraded now ...
Thanks!
Hopefully that should fix the short-ter
On Fri, Aug 17, 2007 at 01:16:22AM -0400, Tom Lane wrote:
> That seems like it'd fix the problem for expression indexes on
> to_tsvector calls, but I don't see how it fixes the problem for
> triggers. We don't have any clear path for making trigger arguments
> be anything but a list of strings.
I
On Thu, 16 Aug 2007, Tom Lane wrote:
I wrote:
We can't put tsvector_update_trigger() into core in anything like its
current form. As is, it will take an unqualified function name, look
it up, and call it. The prospects for subversion by search path
manipulation are obvious, and even if you ar
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Uh, no. Function names for example are subject to search-path
>> confusion.
> Wait, are they? They are in PL languages but only because most
> languages store their source code as text just as is happening here.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
>> Wouldn't treating them as actual objects remove this whole issue?
>
> Uh, no. Function names for example are subject to search-path
> confusion.
Wait, are they? They are in PL languages but only because most
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> Wouldn't treating them as actual objects remove this whole issue?
Uh, no. Function names for example are subject to search-path
confusion.
regards, tom lane
---(end of broadcast)---
On 8/16/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Actually ... I'm suddenly not happy about the choice to put text search
> configurations etc. into schemas at all. We've been sitting here and
> assuming that to_tsvector('english', my_text_col) has a well defined
> meaning --- but as the patch st
I wrote:
> We can't put tsvector_update_trigger() into core in anything like its
> current form. As is, it will take an unqualified function name, look
> it up, and call it. The prospects for subversion by search path
> manipulation are obvious, and even if you aren't concerned about
> malicious
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
> Joshua D. Drake wrote:
>>> These patches will be held for 8.4:
>>>
>>> o Grouped Index Tuples (GIT)
>>> o Bitmap scan changes
>>> o Stream bitmaps (API change for Group Index Tuples)
>>> o Maintaining cluster
Joshua D. Drake wrote:
> > These patches will be held for 8.4:
> >
> > o Grouped Index Tuples (GIT)
> > o Bitmap scan changes
> > o Stream bitmaps (API change for Group Index Tuples)
> > o Maintaining cluster order on insert
> >
> > I believe Heikki is in agreement on this.
>
Tom Lane wrote:
> I find the following additions to pg_proc in the current tsearch2 patch:
It seems a lot of these are useless and just bloat. I will mark a few:
>proc | prorettype
> --+
> pg_ts_parser_is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
> I somehow feel that if HOT wasn't being considered for 8.3 we might have
> gotten GIT, but with limited resources I think there was more focus on
> HOT, perhaps righ
Tom Lane wrote:
> We can't put tsvector_update_trigger() into core in anything like its
> current form. As is, it will take an unqualified function name, look
> it up, and call it. The prospects for subversion by search path
> manipulation are obvious, and even if you aren't concerned about
> mal
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> So instead of pressing to try to get something into 8.3, I would rather
> >> we stand back and think about it some more.
>
> > I understand why you are saying hold for 8.4, but this issue came up in
> > the middle
We can't put tsvector_update_trigger() into core in anything like its
current form. As is, it will take an unqualified function name, look
it up, and call it. The prospects for subversion by search path
manipulation are obvious, and even if you aren't concerned about
malicious attacks, the effect
I find the following additions to pg_proc in the current tsearch2 patch:
proc | prorettype
--+
pg_ts_parser_is_visible(oid) | boolean
pg_ts_dict_is_visible(oid) | boolean
pg_ts_te
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, August 16, 2007 23:16:09 +0200 Magnus Hagander
<[EMAIL PROTECTED]> wrote:
>
> But my question still stands - how much work to stop-gap fix it on the
> old one?
rsync should be upgraded now ...
-
Marc G. Fournier Hu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> On Wed, 2007-08-15 at 11:54 -0400, Bruce Momjian wrote:
>>> A third idea would be for a heap scan to check if all rows are visible
>>> and if so set a per-table flag which can be checked by index scans.
> I think it's too coarse-grained to be really us
Marc G. Fournier wrote:
>
>> Marc - how much work to update that one on the old server? I know you
>> have a new one coming up, but as a stop-gap fix on the old one?
>
> The new one is just waiting on your time scheduale ... its there ready for
> you
> though :)
No, that's still waiting on yo
On Thu, Aug 16, 2007 at 04:13:55PM +0200, Florian G. Pflug wrote:
> Tom Lane wrote:
> >Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>Is enlarging the xid field something we should consider for 8.4?
> >
> >No. We just got the tuple header down to 24 bytes, we are not going
> >to give that back and
2007/8/16, Oleg Bartunov <[EMAIL PROTECTED]>:
> On Thu, 16 Aug 2007, Pavel Stehule wrote:
>
> > Hello
> >
> > I tested contrib package intarray and gist support from this package.
> > I was surpirised. Index building needed lot of time.
> >
> > 10K fields .. 106sec
> > 20K f ..265 sec
> > 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, August 16, 2007 18:29:22 +0200 Magnus Hagander
<[EMAIL PROTECTED]> wrote:
> Marc - how much work to update that one on the old server? I know you
> have a new one coming up, but as a stop-gap fix on the old one?
The new one is ju
Alvaro Herrera wrote:
How do you create the copy of the repo to build? One idea would be to
explicitely skip files that appear on .cvsignore (and maybe croak about
them).
We are supposed to croak - see
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbuildfarm/client-code/run_build.pl.d
On Thu, Aug 16, 2007 at 04:06:35PM -0400, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > On Wed, 2007-08-15 at 11:54 -0400, Bruce Momjian wrote:
> > > I have added another idea for index-only scans to the TODO list:
> > >
> > > > A third idea would be for a heap scan to check if all rows are visi
Andrew Dunstan wrote:
>
>
> Michael Meskes wrote:
>> The backend has:
>>
>> $(srcdir)/gram.c: $(srcdir)/parse.h ;
>>
>> $(srcdir)/parse.h: gram.y
>>
>> So except for the different naming it's the same. However, we haven't
>> had that problem with the backend so far, or did we?
>>
>> What do I fail
Jeff Davis wrote:
> On Wed, 2007-08-15 at 11:54 -0400, Bruce Momjian wrote:
> > I have added another idea for index-only scans to the TODO list:
> >
> > > A third idea would be for a heap scan to check if all rows are visible
> > > and if so set a per-table flag which can be checked by index s
Josh Berkus wrote:
> All,
>
> First off, I'll assert that backup/restore is a serious issue and while the
> folks who want Tsearch in core now are dismissing it, we'll be fielding the
> complaints later. Any solution which involves setting a GUC at restore time
> *which could vary per table or
On Wed, 2007-08-15 at 11:54 -0400, Bruce Momjian wrote:
> I have added another idea for index-only scans to the TODO list:
>
> > A third idea would be for a heap scan to check if all rows are visible
> > and if so set a per-table flag which can be checked by index scans.
> > Any change to th
Added to TODO:
* Reduce XID consumption of read-only queries
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00516.php
---
Florian G. Pflug wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
On Thu, 16 Aug 2007, Pavel Stehule wrote:
Hello
I tested contrib package intarray and gist support from this package.
I was surpirised. Index building needed lot of time.
10K fields .. 106sec
20K f ..265 sec
30Kf .. 450 sec
50Kf .. 1283sec
building gin index for 50K
On Thu, 16 Aug 2007, Josh Berkus wrote:
All,
First off, I'll assert that backup/restore is a serious issue and while the
folks who want Tsearch in core now are dismissing it, we'll be fielding the
complaints later. Any solution which involves setting a GUC at restore time
*which could vary per
Hello
I tested contrib package intarray and gist support from this package.
I was surpirised. Index building needed lot of time.
10K fields .. 106sec
20K f ..265 sec
30Kf .. 450 sec
50Kf .. 1283sec
building gin index for 50K fields needed 0.5sec
Regards
Pavel Stehule
All,
First off, I'll assert that backup/restore is a serious issue and while the
folks who want Tsearch in core now are dismissing it, we'll be fielding the
complaints later. Any solution which involves setting a GUC at restore time
*which could vary per table or even column* isn't acceptable.
Michael Meskes wrote:
The backend has:
$(srcdir)/gram.c: $(srcdir)/parse.h ;
$(srcdir)/parse.h: gram.y
So except for the different naming it's the same. However, we haven't
had that problem with the backend so far, or did we?
What do I fail to see?
We have had problems in the past. If
On Thu, Aug 16, 2007 at 08:24:14AM -0700, Darcy Buskermolen wrote:
> This is something I do not recall doing, however it's possible. though this
> does make me ask why are the build dependencies in the Makefile are not
> properly setup to tell that the .y needs to be rebuilt (which I would assum
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing
Andrew Dunstan wrote:
>
>
> Darcy Buskermolen wrote:
>>> This sort of thing is usually a
>>> symptom of somebody having run a build in the repo directly, a thing
>>> that buildfarm owners have been repeatedly advised not to do.
>>>
>>
>> This is something I do not recall doing, however it's po
Gregory Stark <[EMAIL PROTECTED]> writes:
> Is there a null configuration which could be the default for the casts?
If we did that then there would be no point in having a GUC variable,
because it wouldn't control anything.
While that is certainly an alternative solution, I think it's riskier
tha
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> There seems to be something wrong with this commit notification. This
>> file
>
>>> pgsql/src/test/regress/expected:
>>> foreign_key.out (r1.44 -> r1.45)
>>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected
On Thursday 16 August 2007 04:29:41 Andrew Dunstan wrote:
> Michael Meskes wrote:
> > Hi,
> >
> > we have two build farm members failing to make since I committed teh
> > ecpg changes: echidna and herring.
> >
> > It looks like they are still using an old preproc.c although they
> > checked out the
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> There seems to be something wrong with this commit notification. This
> file
>> pgsql/src/test/regress/expected:
>> foreign_key.out (r1.44 -> r1.45)
>> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/foreign_key.out?r1=1.44&
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing, however it's possible. though this
does make me ask why a
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Yeah, unfortunately we overlooked the implications of the conversion to
> tsvector being environment-dependent. Those opclasses will have to go
> away again. AFAICS the only safe way to build an index directly on a
> text column is
>
> CREATE INDEX idxna
On Thu, Aug 16, 2007 at 12:45:23PM -0300, Rodrigo Hjort wrote:
> Dear Hackers,
>
> Could you point me the first version PostgreSQL started to support
> Deferred Constraints (ie: DEFERRABLE keyword on foreign keys
> creation)? I guess it is earlier than 7.0, right?
You could look through the relea
Dear Hackers,
Could you point me the first version PostgreSQL started to support
Deferred Constraints (ie: DEFERRABLE keyword on foreign keys
creation)? I guess it is earlier than 7.0, right?
--
Regards,
Rodrigo Hjort
http://icewall.org/~hjort
---(end of broadcast)-
[EMAIL PROTECTED] (Gregory Stark) writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>
>> Gregory Stark wrote:
>>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>>
That general approach of storing a common part leading part just once is
called prefix compression. Yeah, it he
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Is enlarging the xid field something we should consider for 8.4?
No. We just got the tuple header down to 24 bytes, we are not going
to give that back and then some.
If you are processing 6K transactions per second, you can afford to
Michael Paesold <[EMAIL PROTECTED]> writes:
> Teodor Sigaev wrote:
>>> 2) added operator class for text and varchar
>>> CREATE INDEX idxname ON tblname USING GIN ( textcolumn );
> So just remove the operator class or don't specify it as default
> operator class for GIN, and the thing is gone. Per
On Wed, 2007-08-15 at 12:49 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Maybe we can do something to reduce the xid consumption? For example,
> > reuse xids for read-only queries.
>
> Hmm, that's an idea.
That would be a very useful idea for additional scalability
Michael Meskes wrote:
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone pleas
Bruce Momjian wrote:
Uh, how are we going to prevent the auto-casting to tsvector from using
the default GUC config, e.g. CREATE INDEX i ON x USING GIN(col)?
This is where I started to see the need for education and error-prone
nature of the default GUC just wasn't worth having it, though I know
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone please enlighten me?
Michael
-
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>
>>> That general approach of storing a common part leading part just once is
>>> called prefix compression. Yeah, it helps a lot on long text fields.
>>> Tree structures
53 matches
Mail list logo
