On Fri, 16 Mar 2007, Magnus Hagander wrote:
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just CREATE INDEX fti1 on t1(c1) USING
FULLTEXT and then be done with it. This patch isn't going to give people
that.
Since we use
Hi,
What's the expected result if the tuple from subselect is more than 1?
Error, per SQL99 section 7.14:
1) If the cardinality of a row subquery is greater than 1
(one),
then an exception condition is raised: cardinality violation.
I expect no update at all in case
Yeah, that one. It might be more consistent to spell it as fulltext_ops
but I wouldn't insist on it.
Hmm, you are prompting an idea to me how to simplify usage of full text index in
simple cases.
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass
I'm also concerned about the stability of the tsearch api in general wrt
including it in core. Currently the recommended upgrade practice is to
dump/reload without tsearch, installing the new servers version of tsearch
That is because pg_ts* tables changes, function names and internal API.
Grzegorz Jaskiewicz wrote:
Because CLUSTER is divided into two major operations, (data reordering,
index rebuild) - I see it this way:
CLUSTER on I: index name T: table name, data reordering
CLUSTER on I: index name T: table name, index rebuild
Something like that would be nice to see how
Tom Lane wrote:
It turns out that this is because the link command for pltcl includes
-L/usr/lib, so that gets searched before /usr/lib64. And the reason the
command includes that is that that's what it says in TCL_LIB_SPEC in
/usr/lib/tclConfig.sh. There is also a /usr/lib64/tclConfig.sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm observing that is not allowed to LOCK a table in a
STABLE/IMMUTABLE function but at same time is allowed
a SELECT FOR UPDATE.
Is that normal?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with
On Mar 16, 2007, at 9:53 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
Because CLUSTER is divided into two major operations, (data
reordering, index rebuild) - I see it this way:
CLUSTER on I: index name T: table name, data reordering
CLUSTER on I: index name T: table name, index
Am Mittwoch, 14. März 2007 08:01 schrieb Michael Paesold:
Andrew Dunstan wrote:
This strikes me as essential. If the db has a certain encoding ISTM we
are promising that all the text data is valid for that encoding.
The question in my mind is how we help people to recover from the fact
What is the safest way to access/modify the pg_class attribute
and still avoid any race conditions with the other backends ?
A specific example is: To solve the CREATE INDEX problem with
HOT, I am thinking of adding (along with other things) a pg_class
boolean attribute, say hot_update_enable.
Mario Weilguni wrote:
Is there anything I can do to help with this problem? Maybe
implementing a new
GUC variable that turns off accepting wrong encoded sequences (so DBAs
still
can turn it on if they really depend on it)?
I think that this should be done away with unconditionally.
Or does
Albe Laurenz wrote:
Mario Weilguni wrote:
Is there anything I can do to help with this problem? Maybe
implementing a new
GUC variable that turns off accepting wrong encoded sequences (so DBAs
still
can turn it on if they really depend on it)?
I think that this
On Friday 16 March 2007 04:44, Teodor Sigaev wrote:
I'm also concerned about the stability of the tsearch api in general wrt
including it in core. Currently the recommended upgrade practice is to
dump/reload without tsearch, installing the new servers version of
tsearch
That is because
[EMAIL PROTECTED] wrote:
Does hstore nest? My impression is that it doesn't. Which might well not
matter, of course.
If what you mean is to have mappings of mappings then no.
Hstore implements a data type for a (finite) mapping (a set of key - value
pairs, think hash for perl folks),
NikhilS [EMAIL PROTECTED] writes:
To allow both of the above to hold, I think the subselect will have to be
treated like a EXPR_SUBLINK subquery. I was wondering if we have a similar
mechanism for plain selects/subselects to check and restrict their output to
a single row.
No. Offhand I
Teodor Sigaev [EMAIL PROTECTED] writes:
Hmm, you are prompting an idea to me how to simplify usage of full text index
in
simple cases.
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
+1 ... makes the easy cases easy, doesn't make the hard cases any
harder.
BTW,
I don't see how the proposal is going to solve that type of problem, but maybe
I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM will be changed - will anybody except
pghackers see that? New opclass
Pavan Deolasee wrote:
What is the safest way to access/modify the pg_class attribute
and still avoid any race conditions with the other backends ?
A specific example is: To solve the CREATE INDEX problem with
HOT, I am thinking of adding (along with other things) a pg_class
boolean
Hi,
On 3/16/07, Tom Lane [EMAIL PROTECTED] wrote:
NikhilS [EMAIL PROTECTED] writes:
To allow both of the above to hold, I think the subselect will have to
be
treated like a EXPR_SUBLINK subquery. I was wondering if we have a
similar
mechanism for plain selects/subselects to check and
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm observing that is not allowed to LOCK a table in a
STABLE/IMMUTABLE function but at same time is allowed
a SELECT FOR UPDATE.
Really? AFAICS, CommandIsReadOnly() will reject SELECT FOR UPDATE too.
regards, tom lane
Teodor Sigaev wrote:
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass parses the document similarly to_tsvector nad
stores lexemes in gin index. It's a full equalent of
CREATE INDEX ... ( to_tsvector( textcolumn ) )
And, let we define operation text @
Pavan Deolasee [EMAIL PROTECTED] writes:
My understanding is that the backend which sets this attribute
must first acquire a lock on the heap relation of sufficient
strength so as to ensure that there are no concurrent UPDATErs,
update the pg_class row and then release the lock on the
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support:
Tom Lane wrote:
Actually, if you wanted to simplify
life a bit, you could mark fulltext_ops as being the default opclass
for text (and varchar I guess) under GIST and GIN. Then it reduces
to just
CREATE INDEX idxname ON tblname USING gin (textcolumn);
Nice. This gets my vote.
cheers
On Fri, 16 Mar 2007, Joshua D. Drake wrote:
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
ts_ means Text Search, I don't think ft_ (Full Text)
Florian G. Pflug wrote:
Teodor Sigaev wrote:
CREATE INDEX idxname ON tblname USING gin (textcolumn fulltext_ops);
Fulltext_ops opclass parses the document similarly to_tsvector nad
stores lexemes in gin index. It's a full equalent of
CREATE INDEX ... ( to_tsvector( textcolumn ) )
And, let
Oleg Bartunov wrote:
On Fri, 16 Mar 2007, Joshua D. Drake wrote:
One a related note - will to_tsvector and to_tsquery be renamed to
something like ft_parse_text() and ft_parse_query() if tsearch2 goes
Furthering this... perhaps even:
ft_search()
ft_query()
ts_ means Text Search, I don't
Tom Lane wrote:
In what context are you proposing to do that, and won't this
high-strength lock in itself lead to deadlocks?
The whole thing sounds exceedingly ugly anyway --- for example
what happens if the backend doing the CREATE INDEX fails and
is therefore unable to clear the flag
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to look like that's the case.
I think what we need to get
Luis,
This is a proposal for design a new concept for integrated PostGIS
application and how to implement features to improve tracking information
about missing people. This application will be useful in disaster
scenarios, looking for missing kids, rescue kidnapped people, human right
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to look like that's the case.
I
Tom Lane wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
The main objective of HOT is to enable retail vacuum of HOT-updated
tuples. Doing the above would make it useless for that purpose,
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(.
Yes, it looks a bit complex. But IMHO we can get around that.
Do you have any ideas in mind about doing that ?
I thought from the beginning
that CREATE
On Fri, 2007-03-16 at 21:56 +0530, Pavan Deolasee wrote:
Any thoughts on the overall approach ? Any suggestions to
simplify things or any alternate designs ?
Well your design is very different from what we discussed, so I think I
should post my proposed design alongside this, for further
Joshua D. Drake [EMAIL PROTECTED] writes:
Just to throw my two bits in here :). If we do that, how does that
effect the idea that most people in the web world use (id serial primary
key), even though that is not what they are searching on?
affect. But I think you're right that generally
On Tue, 2007-03-13 at 12:00 +0100, Mario Weilguni wrote:
Hi,
I've a problem with a database, I can dump the database to a file, but
restoration fails, happens with 8.1.4.
I reported the same problem a while back:
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00246.php
Some people
Heikki Linnakangas wrote:
Tom Lane wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
The main objective of HOT is to enable retail vacuum of HOT-updated
tuples. Doing the above would make
On Wed, 2007-03-14 at 01:29 -0600, Michael Fuhr wrote:
On Tue, Mar 13, 2007 at 04:42:35PM +0100, Mario Weilguni wrote:
Am Dienstag, 13. März 2007 16:38 schrieb Joshua D. Drake:
Is this any different than the issues of moving 8.0.x to 8.1 UTF8? Where
we had to use iconv?
What issues?
On Fri, 2007-03-16 at 12:40 -0400, Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Just to throw my two bits in here :). If we do that, how does that
effect the idea that most people in the web world use (id serial primary
key), even though that is not what they are searching on?
affect. But I think you're
The current buildfarm webpages make it easy to see when a branch tip
is seriously broken, but it's not very easy to investigate transient
failures, such as a regression test race condition that only
materializes once in awhile. I would like to have a way of seeing
just the failed build attempts
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This is what I suggest.
Provide a tarball of -head with the patch applied.
Here you are:
http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
Provide a couple of use cases that can be run with explanation of how to
verify
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This is what I suggest.
Provide a tarball of -head with the patch applied.
Here you are:
http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
Provide a couple of use cases that can be run with explanation of how to
verify
Tom Lane wrote:
The current buildfarm webpages make it easy to see when a branch tip
is seriously broken, but it's not very easy to investigate transient
failures, such as a regression test race condition that only
materializes once in awhile. I would like to have a way of seeing
just the
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
Tom Lane wrote:
The current buildfarm webpages make it easy to see when a branch tip
is seriously broken, but it's not very easy to investigate transient
failures, such as a regression test race condition that only
materializes once in awhile. I would like to have a way of seeing
just the
On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
I don't see how the proposal is going to solve that type of problem, but
maybe I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM will be changed -
Well, the db is currently running around 13Gb, so that's not something
to be exported lightly ;-)
If we upgraded from Postgres 8.0.x to 8.2.x we could make use of some
features, like dynamic partitioning and copy from queries, that might
make life easier (CP people: that's a hint :-) )
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, the db is currently running around 13Gb, so that's not something
to be exported lightly ;-)
Yeah. I would assume though that the vast bulk of that is captured log
files. For the purposes I'm imagining, it'd be sufficient to export
only the rest
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
Here are my results on a modest 3800X2 2 Gig of ram, RAID 1 dual SATA
Simon Riggs wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
On its own, I don't think this is a sufficiently wide use-case.
Perhaps we should do this PLUS make HOT-semantics optional
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
Here are my results on a modest 3800X2 2 Gig of ram, RAID 1 dual SATA
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, the db is currently running around 13Gb, so that's not something
to be exported lightly ;-)
Yeah. I would assume though that the vast bulk of that is captured log
files. For the purposes I'm imagining, it'd be sufficient
On Fri, 16 Mar 2007, Andrew Dunstan wrote:
OK, for anyone that wants to play, I have created an extract that contains a
summary of every non-CVS-related failure we've had. It's a single table
looking like this:
CREATE TABLE mfailures (
sysname text,
snapshot timestamp without time
On Fri, 2007-03-16 at 16:59 -0400, Alvaro Herrera wrote:
Here's is a very simple, low-tech idea. How about checking whether the
new index requires chilling tuples; if it does, then elog(ERROR) until
all the indexes have been manually chilled, which would be done with an
ALTER INDEX ... CHILL
Robert Treat wrote:
On Friday 16 March 2007 10:45, Teodor Sigaev wrote:
I don't see how the proposal is going to solve that type of problem, but
maybe I am overlooking something?
The same way as other system tables objects, they don't dump, they don't
restore. In 8.3, seems, API to index AM
A month or so back I wrote:
BTW, I think a good case could be made that the core of the problem
is exactly that struct Const doesn't carry typmod, and thus that we
lose information about constructs like 'foo'::char(7). We should fix
that, and also anywhere else in the expression tree
Jeremy Drake wrote:
The dump is just under 1Mb and can be downloaded from
http://www.pgbuildfarm.org/mfailures.dump
Sure about that?
HTTP request sent, awaiting response... 200 OK
Length: 9,184,142 (8.8M) [text/plain]
Damn these new specs. They made me skip a digit.
cheers
andrew
Tom Lane [EMAIL PROTECTED] writes:
ArrayExpr: should adopt the same behavior as Coalesce and
similar nodes, ie, if all the elements show the
same type/typmod then return that typmod
instead of -1
...
Comments,
Gregory Stark [EMAIL PROTECTED] writes:
I'm not entirely convinced by this one. Does that mean expressions like this
would throw an error if col1 was declared as a numeric(1)?
ARRAY[col1] || 10
No, because the result of the || operator won't have a specific typmod.
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm observing that is not allowed to LOCK a table in a
STABLE/IMMUTABLE function but at same time is allowed
a SELECT FOR UPDATE.
Really? AFAICS, CommandIsReadOnly() will reject SELECT FOR UPDATE too.
kalman=# select version();
Gaetano Mendola [EMAIL PROTECTED] writes:
Tom Lane wrote:
Really? AFAICS, CommandIsReadOnly() will reject SELECT FOR UPDATE too.
kalman$# FOR my_port_set IN
kalman$# SELECT a
kalman$# FROM test
kalman$# FOR UPDATE
kalman$# LOOP
Hm, that's a bug --- SPI_cursor_open is
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
Here are my results on a modest 3800X2 2 Gig
63 matches
Mail list logo
