How do we move forward with the CREATE INDEX issue with
HOT ? There are quite a few suggestions and objections.
Can we please discuss and decide on the plan ? I am very
comfortable with the current state of HOT, the results
are encouraging and I hope this issue does not become
a showstopper.
Her
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 r
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_op
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();
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" <[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
...
> Commen
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.
cheer
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 struc
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 wil
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 ... C
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 t
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 sufficien
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
T
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
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
http://pg
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 re
> 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 :-)
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 chang
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 failed
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 broadcast)-
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 th
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
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
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 ac
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
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 s
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?
> >
> > W
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 wou
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 peopl
"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 genera
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 dis
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
>
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, at
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
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
> w
"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
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 fl
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
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 ) )
>
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)
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
and
> 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: +
"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 r
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 @
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
--
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
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
> boole
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 layo
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.
> BT
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
[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
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
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 shoul
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
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.
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
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: T: , data reordering
CLUSTER on I: T: , index rebuild
Something like that would be n
-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 Mozil
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 which
Grzegorz Jaskiewicz wrote:
Because CLUSTER is divided into two major operations, (data reordering,
index rebuild) - I see it this way:
CLUSTER on I: T: , data reordering
CLUSTER on I: T: , index rebuild
Something like that would be nice to see how long each step takes, like
vacuum verbose.
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. Putt
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 pa
62 matches
Mail list logo
