Ühel kenal päeval, N, 2007-03-22 kell 23:30, kirjutas Pavan Deolasee:
>
>
> On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > When CREATE INDEX starts, it acquires ShareLock on the
> table.
> > At this point we may h
On 2007-03-23, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> Thanks, it all made sense to me. My proposal was completely wrong.
Actually, I think your proposal is fundamentally correct, merely incomplete.
Doing octet-based rather than character-based matching of strings is a
_design goal_ of UTF8
On 2007-03-22, Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
>> I found LIKE operators are slower on multi-byte encoding databases
>> than single-byte encoding ones. It comes from difference between
>> MatchText() and MBMatchText().
>
>> We've had an optimizatio
ITAGAKI Takahiro skrev:
I guess it works well for % but not for _ , the latter has to know, how
many bytes the current (multibyte) character covers.
Yes, % is not used in trailing bytes for all encodings, but _ is
used in some of them. I think we can use the optimization for all
of the server
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
> The problem with the like pattern _ is that it has to know how long the
> single caracter is that it should pass over. Say you have a UTF-8 string
> with 2 characters encoded in 3 bytes ('ÖA'). Where the first character
> is 2 bytes:
>
> 0xC3 0x96
On 3/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
The ShareLock taken by CREATE INDEX guarantees all transactions that
wrote data to the table have completed and that no new data can be added
until after the index build commits. So the end of the chain is visible
to CREATE INDEX and won't cha
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > > We've had an optimization for single-byte encodings using
> > > pg_database_encoding_max_length() == 1 test. I'll propose to extend it
> > > in UTF-8 with locale-C case.
> >
> > If this works for UTF8, won't it work for all the backend-legal
> > enc
Simon Riggs wrote:
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data
Jim C. Nasby wrote:
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to al
Peter Eisentraut wrote:
> Mike Rylander wrote:
>> A related question, however: Will the XML features being included in
>> 8.3 support namespace prefix registration?
>
> That is certainly the plan.
Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.
Joshua D.
Hi Hannu,
On 3/22/07 3:21 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
> Maybe monetdb ( http://monetdb.cwi.nl/ ) can be of some inspiration ?
>
> btw, it may be a good idea to have a verion of bizgresMPP which has
> monetdb as partition db, if monetdb is as efficient as they tell it is .
Yep
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So, can't this be improved to allow more aggressive vacuuming?
Not at that level. We do not keep track of the oldest still-used
snapshot in a transaction. I'm dubious that it'd be worth the
bookkeeping trouble to try --- often as not, the problem with
Ühel kenal päeval, N, 2007-03-22 kell 10:19, kirjutas Luke Lonergan:
> Andreas,
>
> On 3/22/07 9:40 AM, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
>
> > Wouldn't it be enough to enable having the toast table on a different
> > table space?
>
> Yes, but the ultimate goal would allow the allocatio
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > In researching, I found we already do this by updating PGPROC.xid for
> > every command in non-serialzable transactions:
>
> Dunno how you arrived at that conclusion, but it's quite wrong.
Looking in the function I now see you are ri
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In researching, I found we already do this by updating PGPROC.xid for
> every command in non-serialzable transactions:
Dunno how you arrived at that conclusion, but it's quite wrong.
regards, tom lane
---
Mike Rylander wrote:
> A related question, however: Will the XML features being included in
> 8.3 support namespace prefix registration?
That is certainly the plan.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
On Thu, 2007-03-22 at 10:36 -0500, andress calderon wrote:
> Hi,
>
> I want to contribute with new features in Data mining. In the
> University of Nariño (Colombia) works in new operators and primitives
> in Knowledge Discovery in Databases and We had integrated several
> operators in a own versi
Bruce Momjian wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > > We wouldn't clean up tuples that are visible to a transaction, but if
> > > you have one long-running transaction like pg_dump in a database with
> > > otherwise short transaction, you'll have a lot of
Chris,
> Hmm. Are you trying to do something sort of like CStore?
>
> http://db.csail.mit.edu/projects/cstore/
>
> That seems to have some relevant ideas...
I think "something like" is a good way to put it. As you know Cstore was a
prototype for Vertica and these are in the same class as Syba
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration? If not, handling arbitrary
XML via XPath that includes unprefixed (default) namespaces (for me
that is the majority of the XML I deal with, and no, I can't chang
On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
> Author states:
>> I understand that XML support is planned and at least partially
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > There is a slight hole in that SERIALIZABLE transactions won't be able
> > to use any indexes they build during their transaction, since they may
> > need to be able to see prior data, but I don't thi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
> Author states:
>> I understand that XML support is planned and at least partially
>> implemented for 8.3, but many production insta
Dave Page wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
> >> features to it.
> >
> > Author states:
> >
> >> I understand that XML support is planned and at least partially
> >> implemented for 8.3, but man
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
>> features to it.
>
> Author states:
>
>> I understand that XML support is planned and at least partially
>> implemented for 8.3, but many production instances will be unab
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Your patch has been added to the PostgreSQL unapplied patches list
> > at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers
> > reviews and approves it.
>
> I was ho
Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list
> at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers
> reviews and approves it.
I was hoping that we're deprecating contrib/xml2,
Andrew Dunstan wrote:
> Would it be better to use some more unlikely name for the dummy root
> element used to process fragments than ?
Why do we even need to support xpath on fragments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
Added to TODO:
* Fix cases where invalid byte encodings are accepted by the database,
but throw an error on SELECT
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
Is anyone working on fixing this bug?
---
Added to TODO for CLUSTER:
o %Add VERBOSE option to report tables as they are processed,
like VACUUM VERBOSE
---
Grzegorz Jaskiewicz wrote:
>
> On Mar 16, 2007, at 9:53 AM, Heikki Linnakangas wrote:
>
>
Jan Wieck wrote:
> On 3/21/2007 10:24 PM, Bruce Momjian wrote:
> > Ah, so you wait for me to go on vacation to apply it! Well, I am back
> > now, buddy. ;-)
>
> Got to use my chances, don't I? :-p
>
> >
> > One thing that bothers me about the patch is that it seems you are
> > adding functiona
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
> On 3/5/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Mi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> There is a slight hole in that SERIALIZABLE transactions won't be able
> to use any indexes they build during their transaction, since they may
> need to be able to see prior data, but I don't think anybody is going to
> complain about that restriction. A
Ühel kenal päeval, N, 2007-03-22 kell 11:08, kirjutas Tom Lane:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > I found LIKE operators are slower on multi-byte encoding databases
> > than single-byte encoding ones. It comes from difference between
> > MatchText() and MBMatchText().
>
> > We've
[EMAIL PROTECTED] ("Luke Lonergan") writes:
> Andreas,
>
> On 3/22/07 9:40 AM, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
>
>> Wouldn't it be enough to enable having the toast table on a different
>> table space?
>
> Yes, but the ultimate goal would allow the allocation of a storage mechanism
> tha
On Thu, 2007-03-22 at 22:11 +0530, Pavan Deolasee wrote:
> With this background, I propose to index ONLY the head of the
> HOT-chain. The TID of the root tuple is used instead of the actual
> TID of the tuple being indexed. This index will not be available to
> the transactions which are started b
Pavan Deolasee wrote:
> My argument is that its enough to index only the LIVE tuple which
> is at the end of the chain if we don't use the new index for queries
> in transactions which were started before CREATE INDEX. I am
> proposing to do that by storing an xid in the pg_index row. A
> special
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
> I was unwilling to compromise to have HOT if only one index existed, but
> IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
> release. (We can always use vertical partitioning techniques to allow
> additional acc
TANIDA Yutaka <[EMAIL PROTECTED]> writes:
> My customer found a problem about PL/pgsql functions and TRUNCATE command.
> If you execute PL/pgsql function includeing TRUNCATE command concurrently,
> causes "relation ... does not exist." or "relation with OID X does not
> exist" against
> exist
On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> When CREATE INDEX starts, it acquires ShareLock on the table.
> At this point we may have one or more HOT-update chains in the
> table. Tuples in this chain may be visible to one or more running
> tran
William Garrison <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What do you mean by "one batch" exactly? Both CREATE and DROP TABLESPACE
>> refuse to run in a transaction block, so I'm confused about this.
> Not a transaction block. A batch of commands submitted to the server in
> a single ca
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> When CREATE INDEX starts, it acquires ShareLock on the table.
> At this point we may have one or more HOT-update chains in the
> table. Tuples in this chain may be visible to one or more running
> transactions. The fact that we have ShareLock on the ta
Andreas,
On 3/22/07 9:40 AM, "Andreas Pflug" <[EMAIL PROTECTED]> wrote:
> Wouldn't it be enough to enable having the toast table on a different
> table space?
Yes, but the ultimate goal would allow the allocation of a storage mechanism
that is unique to each column. The most frequently used mec
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm seeing the following regression failure in PL/Tcl. It seems to be
> > just an ordering issue, and the order in which a trigger is fired.
>
> Works on my x86_64 box. Are you running the test in C locale (because
> it looks a bit
Alvaro Herrera wrote:
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm seeing the following regression failure in PL/Tcl. It seems to be
> just an ordering issue, and the order in which a trigger is fired.
Works on my x86_64 box. Are you running the test in C locale (because
it looks a bit like a sort-ordering issue)
Luke Lonergan wrote:
> I advocate the following:
>
> - Enable specification of TOAST policy on a per column basis
>
> As a first step, then:
>
> - Enable vertical partitioning of tables using per-column specification of
> storage policy.
>
Wouldn't it be enough to enable having the toast table o
On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in pg_index. The idea is that when a new index is
created, it has its HOT boolean set to false and indexes all tuples and
ignores HOT chains. Then d
Alvaro Herrera wrote:
> Hi,
>
> I'm seeing the following regression failure in PL/Tcl. It seems to be
> just an ordering issue, and the order in which a trigger is fired.
>
> This is a pristine, freshly updated copy of CVS head as of right now.
I removed the derived files (moral equivalent of m
Hi,
I'm seeing the following regression failure in PL/Tcl. It seems to be
just an ordering issue, and the order in which a trigger is fired.
This is a pristine, freshly updated copy of CVS head as of right now.
I'm not sure why the buildfarm is not having this problem.
alvherre=# select versi
Bruce Momjian wrote:
> Please read the developer's FAQ on the web site first. That should have
> all the information you need.
Andress,
First let me say welcome! We are always glad to have more contributors.
As Bruce said, the first step would be reading the developers FAQ. You
can find it here:
Please read the developer's FAQ on the web site first. That should have
all the information you need.
---
andress calderon wrote:
> Hi,
>
> I want to contribute with new features in Data mining. In the University of
> Nar
Hi,
I want to contribute with new features in Data mining. In the University of
Nariño (Colombia) works in new operators and primitives in Knowledge
Discovery in Databases and We had integrated several operators in a own
version named PostgresKDD, We like integrate this features in the official
I advocate the following:
- Enable specification of TOAST policy on a per column basis
As a first step, then:
- Enable vertical partitioning of tables using per-column specification of
storage policy.
- Luke
On 3/21/07 1:12 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
>
> Is this a TODO?
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I found LIKE operators are slower on multi-byte encoding databases
> than single-byte encoding ones. It comes from difference between
> MatchText() and MBMatchText().
> We've had an optimization for single-byte encodings using
> pg_database_encoding_
Hubert FONGARNAND <[EMAIL PROTECTED]> writes:
> I'm looking for a way to regenerate the plpgsql function cache, without
> CREATE OR REPLACE function or restarting database...
You don't have to restart the whole database, just start fresh connections.
regards, tom lane
---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Another change that could be done to Dllist is removing the Dllist
> pointer from the Dlelem struct:
I think this is a bad idea. The patch you propose makes
CatCacheRemoveCTup significantly more expensive (extra hash
calculation). Moreover, the saving
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
>> Added to TODO:
>> o During index creation, pre-sort the tuples to improve build speed
> Maybe the TODO text should mention, that it is about HASH indexes ?
It's under the hash-ind
Hannu Krosing wrote:
> ?hel kenal p?eval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
> > Added to TODO:
> >
> > o During index creation, pre-sort the tuples to improve build speed
> >
> > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
>
> Maybe the TODO
On 3/22/07, Hubert FONGARNAND <[EMAIL PROTECTED]> wrote:
Hi,
I'm looking for a way to regenerate the plpgsql function cache, without CREATE
OR REPLACE function or restarting database...
Sometimes, tables could be dropped and recreated, and then all our function
working on these tables fail
Another change that could be done to Dllist is removing the Dllist
pointer from the Dlelem struct:
Index: src/include/lib/dllist.h
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/include/lib/dllist.h,v
retrieving revision 1.27
diff -c
On 3/22/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
On 3/22/07, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> > speaking with pavan off list he seems to think that only 'create
> > index' is outside transaction, not the other ddl flavors of it because
> > they are generally acquiring a excl lock. so
On 3/21/2007 10:24 PM, Bruce Momjian wrote:
Ah, so you wait for me to go on vacation to apply it! Well, I am back
now, buddy. ;-)
Got to use my chances, don't I? :-p
One thing that bothers me about the patch is that it seems you are
adding functionality that allows you to enable/disable tr
Hello,
There are many users (especially novice) asking about better and
easier configuration of tsearch2, which is quite complicated
currently. Even new FTS features in 8.3 (e.g. much clearer
configuration with SQL commands) won't help much for users that want
simple "several clicks" setup of a s
Pavan Deolasee wrote:
What I am hearing from many users is that its probably not such
a nice thing to put such restriction. Thats fair. It really helps to think
about a solution once you know what is acceptable and what is not.
That's likely to be the reaction for almost any restriction you ca
Hi,
I'm looking for a way to regenerate the plpgsql function cache, without
CREATE OR REPLACE function or restarting database...
Sometimes, tables could be dropped and recreated, and then all our
function working on these tables failed...
In fact we've more than 100 functions in our intranet datab
On 3/22/07, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> speaking with pavan off list he seems to think that only 'create
> index' is outside transaction, not the other ddl flavors of it because
> they are generally acquiring a excl lock. so, in that sense it is
> possibly acceptable to me although
> speaking with pavan off list he seems to think that only 'create
> index' is outside transaction, not the other ddl flavors of it because
> they are generally acquiring a excl lock. so, in that sense it is
> possibly acceptable to me although still a pretty tough pill to
> swallow (thinking, guc
On 3/21/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I guess this matches this TODO item:
> o Allow selection of individual object(s) of all types, not just
> tables
(...)
Code-wise, the patch seems a bit of a mess too --- it will certainl
Ühel kenal päeval, K, 2007-03-21 kell 17:25, kirjutas Bruce Momjian:
> Added to TODO:
>
> o During index creation, pre-sort the tuples to improve build speed
>
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Maybe the TODO text should mention, that it is abou
71 matches
Mail list logo
