On Tue, Apr 03, 2007 at 01:06:38PM -0400, Tom Lane wrote:
I think it's probably defensible for non-Unicode encodings. To do
otherwise would require (a) figuring out what the equivalent concept to
code point is for each encoding, and (b) having a separate code path
for each encoding to perform
Mark Dilger wrote:
What I suggest (and what Oracle implements, and isn't CHR() and
ASCII()
partly for Oracle compatibility?) is that CHR() and ASCII()
convert between a character (in database encoding) and
that database encoding in numeric form.
Looking at Oracle documentation, it appears
What do others think? Should the argument to CHR() be a
Unicode code point or the numeric representation of the
database encoding?
When the database uses a single byte encoding, the chr function takes
the binary byte representation as an integer number between 0 and 255
(e.g. ascii code).
When the database uses a single byte encoding, the chr function takes
the binary byte representation as an integer number between 0 and 255
(e.g. ascii code).
When the database encoding is one of the unicode encodings it takes a
unicode code point.
This is also what Oracle does.
Sorry, but
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Great, patch applied and TODO item removed.
If you are already patching, please apply the following patch also.
It removes last remaining casts inside struct definitions.
Such usage is bad practice, as it hides problems from compiler.
Reason
This used to work in 8.2:
psql postgres -c VACUUM table1; SELECT now()
But in cvs head it throws an error:
ERROR: VACUUM cannot be executed from a function or multi-command string
This must be because of the recent changes to PreventTransactionChain.
Should we try to keep the old behavior
This used to work in 8.2:
psql postgres -c VACUUM table1; SELECT now()
But in cvs head it throws an error:
ERROR: VACUUM cannot be executed from a function or multi-command string
This must be because of the recent changes to PreventTransactionChain.
Should we try to keep the old behavior
On Tue, 2007-04-03 at 10:37 -0700, Jeff Davis wrote:
The primary aspect of my patch, the Synchronized Scanning, performed
great though. Even the CFQ scheduler, that does not appear to properly
read ahead, performed substantially better than plain 8.2.3. And even
better, Simon's patch
When the database uses a single byte encoding, the chr function
takes
the binary byte representation as an integer number between 0 and
255
(e.g. ascii code).
When the database encoding is one of the unicode encodings it takes
a
unicode code point.
This is also what Oracle does.
On Mon, 2007-04-02 at 21:16 -0400, Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
It looks like the bgwriter gets starved waiting on the
CheckpointStartLock. The CheckpointStartLock is held in shared mode over
an XLogFlush when
On Mon, 2007-04-02 at 22:23 -0400, Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
... tuning the TOAST parameters seems like
something we understand well enough already, we just need to put some
cycles into testing different alternatives. I
Hi,
NikhilS wrote:
The following things are TODOs:
iv) Auto generate rules using the checks mentioned for the partitions, to
handle INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child.
Note that checks specified directly on the master table will get
inherited
automatically.
Hi,
I appreciate you efforts, but I'm not sure if this has been discussed
Thanks Markus.
enough. There seem to be two ideas floating around:
- you are heading for automating the current kludge, which involves
creating partitions and constraints by hand. AFAICT, you want to
Martijn van Oosterhout wrote:
On Tue, Apr 03, 2007 at 01:06:38PM -0400, Tom Lane wrote:
I think it's probably defensible for non-Unicode encodings. To do
otherwise would require (a) figuring out what the equivalent concept to
code point is for each encoding, and (b) having a separate code
Am Mittwoch, 4. April 2007 14:43 schrieb Nikolay Samokhvalov:
Why do we even need to support xpath on fragments?
Why not? I find it useful and convenient.
Well, rather than inventing bogus root wrapper elements, why not let users
call xmlelement() to produce the wrapper element themselves?
On 2007-04-04, Alvaro Herrera [EMAIL PROTECTED] wrote:
Right -- IMHO what we should be doing is reject any input to chr() which
is beyond plain ASCII (or maybe 255), and create a separate function
(unicode_char() sounds good) to get an Unicode character from a code
point, converted to the
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2007-04-04 at 14:20 +0200, Markus Schiltknecht wrote:
Both proposals do not have much to do with the missing multi-table
indices. It's clear to me that we have to implement those someday,
anyway.
I agree with much of your post, though this
Simon Riggs wrote:
My hope is to have a mechanism to partition indexes or recognise that
they are partitioned, so that a set of provably-distinct unique indexes
can provide the exact same functionlity as a single large unique index,
just without the management nightmare.
Will this address
Hi,
NikhilS wrote:
Our current partitioning solution is based on inheritance. With that in
mind, for 8.3 I thought an implementation based on auto rules creation
would be the way to go.
That's completely reasonable. And as I've said, it's probably even a
step towards what I've outlined
Alvaro Herrera [EMAIL PROTECTED] writes:
Right -- IMHO what we should be doing is reject any input to chr() which
is beyond plain ASCII (or maybe 255), and create a separate function
(unicode_char() sounds good) to get an Unicode character from a code
point, converted to the local
Heikki Linnakangas [EMAIL PROTECTED] writes:
This used to work in 8.2:
psql postgres -c VACUUM table1; SELECT now()
But in cvs head it throws an error:
ERROR: VACUUM cannot be executed from a function or multi-command string
That's intentional. It worked only for rather small values of
Hi,
Simon Riggs wrote:
I agree with much of your post, though this particular point caught my
eye. If you'll forgive me for jumping on an isolated point in your post:
No problem.
Multi-table indexes sound like a good solution until you consider how
big they would be. The reason we need a
Hi,
Gregory Stark wrote:
Put another way, multi-table indexes defeat the whole purpose of having
partitioned the table in the first place. If you could have managed a single
massive index then you wouldn't have bothered partitioning.
That depends very much on the implementation of the
Andrew - Supernews [EMAIL PROTECTED] writes:
Thinking about this made me realize that there's another, ahem, elephant
in the room here: convert().
By definition convert() returns text strings which are not valid in the
server encoding. How can this be addressed?
Remove convert(). Or at least
On Wed, 2007-04-04 at 16:31 +0200, Markus Schiltknecht wrote:
But how to create an (unique) index which is completely different from
the partitioning key?
Don't?
Most high volume tables are Fact tables with potentially more than 1 row
per Object/Dimension, so the unique index isn't
On Wed, Apr 04, 2007 at 10:22:28AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Right -- IMHO what we should be doing is reject any input to chr() which
is beyond plain ASCII (or maybe 255), and create a separate function
(unicode_char() sounds good) to get an Unicode
Alvaro Herrera [EMAIL PROTECTED] writes:
Right -- IMHO what we should be doing is reject any input to chr() which
is beyond plain ASCII (or maybe 255), and create a separate function
(unicode_char() sounds good) to get an Unicode character from a code
point, converted to the local
Tatsuo Ishii wrote:
BTW, every encoding has its own charset. However the relationship
between encoding and charset are not so simple as Unicode. For
example, encoding EUC_JP correponds to multiple charsets, namely
ASCII, JIS X 0201, JIS X 0208 and JIS X 0212. So a function which
returns a
Am Mittwoch, 4. April 2007 16:22 schrieb Tom Lane:
Alvaro Herrera [EMAIL PROTECTED] writes:
Right -- IMHO what we should be doing is reject any input to chr() which
is beyond plain ASCII (or maybe 255), and create a separate function
(unicode_char() sounds good) to get an Unicode character
Hi,
Simon Riggs wrote:
Most high volume tables are Fact tables with potentially more than 1 row
per Object/Dimension, so the unique index isn't appropriate in those
cases.
When partitioning a Major Entity its much easier to regard the PK as the
partitioning key + unique key, which is
On Wed, Apr 04, 2007 at 10:07:39AM -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
My hope is to have a mechanism to partition indexes or recognise
that they are partitioned, so that a set of provably-distinct
unique indexes can provide the exact same functionlity as a single
large unique
Albe Laurenz wrote:
There's one thing that strikes me as weird in your implementation:
pgsql=# select chr(0);
ERROR: character 0x00 of encoding SQL_ASCII has no equivalent in
UTF8
0x00 is a valid UNICODE code point and also a valid UTF-8 character!
It's not my code that rejects this. I'm
Tatsuo Ishii wrote:
SNIP. I think we need to continute design discussion, probably
targetting for 8.4, not 8.3.
The discussion came about because Andrew - Supernews noticed that chr()
returns invalid utf8, and we're trying to fix all the bugs with invalid
utf8 in the system. Something
Mark Dilger [EMAIL PROTECTED] writes:
Albe Laurenz wrote:
0x00 is a valid UNICODE code point and also a valid UTF-8 character!
It's not my code that rejects this. I'm passing the resultant string to
the pg_verify_mbstr(...) function and it is rejecting a null. I could
change that, of
On Wed, 2007-04-04 at 10:40 +0100, Simon Riggs wrote:
That makes no sense to me, so it's probably a fluke (by which I mean
some other activity on the system, perhaps swapping some large
applications). The second two tests are consistent with all the other
numbers I got, but the first one
Patch applied. Thanks.
---
Marko Kreen wrote:
On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Great, patch applied and TODO item removed.
If you are already patching, please apply the following patch also.
It
On 4/4/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Mittwoch, 4. April 2007 14:43 schrieb Nikolay Samokhvalov:
Why do we even need to support xpath on fragments?
Why not? I find it useful and convenient.
Well, rather than inventing bogus root wrapper elements, why not let users
call
Hello all!
This is my first post! I am interested in finding out what queries have
been made against a particular database in postgres. The version of Postgres
is 8.0 running on Mandrake 10. The queries are made by client computers
over the network. What steps must I take to accomplish such a
On 3/27/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on this? Peter thought the consistency makes sense, but if
we can provide functionality that doesn't require libxml, why not
do it?
I'm still for --enable-xml and putting _everything_ XML-related under this
option. My main
On 3/23/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Andrew Dunstan wrote:
Would it be better to use some more unlikely name for the dummy root
element used to process fragments than x ?
Why do we even need to support xpath on fragments?
Why not? I find it useful and convenient.
--
Best
Markus Schiltknecht [EMAIL PROTECTED] writes:
CREATE INDEX x ON test(a, b, c);
That's why I'd say, the first column of an index would have to be equal to all
of the columns used in the partitioning key.
That's certainly the simple case. It would be nice to be able to create an
index like
In this thread:
http://archives.postgresql.org/pgsql-bugs/2007-03/msg00145.php
we eventually determined that the reported lockup had three components:
(1) something (still not sure what --- Martin and Mark, I'd really like
to know) was issuing random SIGTERMs to various postgres processes
Hi,
Gregory Stark wrote:
However there are also cases such as where you have a=0..99 in one partition
and a=100..199 in partition two, etc. It could still automatically build
indexes on (a,b,c) on each partition and somehow note that the unique
constraint is guaranteed across the whole
On Wed, 2007-04-04 at 10:23 -0700, Jeff Davis wrote:
- a hash join
This is where I got stuck.
* If it's one big ( NBuffers/2 ) table and one small table, the small
table will only serve to occupy some shared_buffers (right?
* If it's two big tables, a join would be a major operation. I
On Wed, 2007-04-04 at 20:55 +0200, Markus Schiltknecht wrote:
Questioning the other way around: do we need any sort of multi-table
indexes at all, or isn't it enough to teach the planner and executor how
to intelligently scan through (possibly) multiple indexes to get what is
requested?
Simon Riggs wrote:
On Wed, 2007-04-04 at 20:55 +0200, Markus Schiltknecht wrote:
Questioning the other way around: do we need any sort of multi-table
indexes at all, or isn't it enough to teach the planner and executor how
to intelligently scan through (possibly) multiple indexes to get what
David Fetter wrote:
On Wed, Apr 04, 2007 at 10:07:39AM -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
My hope is to have a mechanism to partition indexes or recognise
that they are partitioned, so that a set of provably-distinct
unique indexes can provide the exact same functionlity
Hi,
Joshua D. Drake wrote:
If we don't have multi-table indexes how do we enforce a primary key
against a partitioned set?
The executor would have to be clever enough to not do a single index
scan, but possibly scan through multiple indexes when asking for
uniqueness, depending on the
Simon Riggs wrote:
The planner already uses the Append node to put together multiple plans.
The great thing is it will put together IndexScans and SeqScans as
applicable. No need for multi-scans as a special node type.
Yes... only that mixing 'concurrent' index scans in the right order
would
Andrew Dunstan wrote:
David Fetter wrote:
That would be where the provably-distinct part comes in, so yes.
That assumes you can provide some provably distinct test. In the general
case I have in mind that isn't so.
Could you please give a somewhat more concrete example, I'm not
following
Markus Schiltknecht wrote:
Andrew Dunstan wrote:
David Fetter wrote:
That would be where the provably-distinct part comes in, so yes.
That assumes you can provide some provably distinct test. In the
general case I have in mind that isn't so.
Could you please give a somewhat more concrete
Simon Riggs wrote:
On Mon, 2007-04-02 at 22:23 -0400, Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
... tuning the TOAST parameters seems like
something we understand well enough already, we just need to put some
cycles into testing
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Having both default GUC and individual table-level WITH parameters seems
like the best way to me.
Agreed.
There's an extremely good reason not to have a GUC variable, which is
that changes in it would fail to reflect into decisions
Hi,
Andrew Dunstan wrote:
I guess my point was really that multi-table indexes might have uses
beyond partitioning.
Aha, now I understand. Thanks for the clarification.
Say I have two tables, each with a field FKed to a field in a third
table. I'd like to create the values to be unique
On Wed, 2007-04-04 at 12:10 -0700, Joshua D. Drake wrote:
Simon Riggs wrote:
On Wed, 2007-04-04 at 20:55 +0200, Markus Schiltknecht wrote:
Questioning the other way around: do we need any sort of multi-table
indexes at all, or isn't it enough to teach the planner and executor how
to
Nikolay Samokhvalov wrote:
On 3/27/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on this? Peter thought the consistency makes sense, but if
we can provide functionality that doesn't require libxml, why not
do it?
I'm still for --enable-xml and putting _everything_
On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Having both default GUC and individual table-level WITH parameters seems
like the best way to me.
Agreed.
There's an extremely good reason not to have a GUC variable, which
On Wednesday 04 April 2007 09:19, NikhilS wrote:
Our current partitioning solution is based on inheritance. With that in
mind, for 8.3 I thought an implementation based on auto rules creation
would be the way to go.
The only problem I have with this is that the shops I know with big
Robert Treat wrote:
On Wednesday 04 April 2007 09:19, NikhilS wrote:
Our current partitioning solution is based on inheritance. With that in
mind, for 8.3 I thought an implementation based on auto rules creation
would be the way to go.
The only problem I have with this is that the shops I
Simon Riggs wrote:
On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Having both default GUC and individual table-level WITH parameters seems
like the best way to me.
Agreed.
There's an extremely good reason not to
Is there any reason we don't have an abs() function for intervals?
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Hi,
I cannot see any docs about pg_internal_init files in our docs. I got an
e-mail today regarding this issue and it says here are ~300
pg_internal_init.* files in data directory. There is only 1 database in
the cluster. Also, he says PostgreSQL crashes sometimes during the day
(this is another
Tatsuo Ishii wrote:
SNIP. I think we need to continute design discussion, probably
targetting for 8.4, not 8.3.
The discussion came about because Andrew - Supernews noticed that chr()
returns invalid utf8, and we're trying to fix all the bugs with invalid
utf8 in the system.
Andrew Dunstan wrote:
Is there any reason we don't have an abs() function for intervals?
No one has ever asked for it.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive,
On Apr 3, 5:37 pm, [EMAIL PROTECTED] (4wheels) wrote:
Hello all!
This is my first post! I am interested in finding out what queries have
been made against a particular database in postgres. The version of Postgres
is 8.0 running on Mandrake 10. The queries are made by client computers
over
Now that we are in feature freeze, I wanted to outline a few things
people can anticipate during this period.
First, you might notice I am trying to stick to a schedule and move the
process along as best as I can. It isn't that I want to be harsh, but
the community wants to get 8.3 released as
Tatsuo Ishii wrote:
BTW, every encoding has its own charset. However the relationship
between encoding and charset are not so simple as Unicode. For
example, encoding EUC_JP correponds to multiple charsets, namely
ASCII, JIS X 0201, JIS X 0208 and JIS X 0212. So a function which
Andrew - Supernews [EMAIL PROTECTED] writes:
Thinking about this made me realize that there's another, ahem, elephant
in the room here: convert().
By definition convert() returns text strings which are not valid in the
server encoding. How can this be addressed?
Remove convert(). Or
Simon Riggs [EMAIL PROTECTED] writes:
If we don't have multi-table indexes how do we enforce a primary key
against a partitioned set? What about non primary keys that are just
UNIQUE? What about check constraints that aren't apart of the exclusion?
I can come up with arbitrary examples
Tom Lane [EMAIL PROTECTED] writes:
What I would definitely like to see for 8.3 is some performance testing
done to determine whether we ought to change the current defaults.
(Both TOAST_TUPLES_PER_PAGE and EXTERN_TUPLES_PER_PAGE ought to be looked
at.)
It will take some thinking before it's
On 2007-04-05, Tatsuo Ishii [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
Thinking about this made me realize that there's another, ahem, elephant
in the room here: convert().
By definition convert() returns text strings which are not valid in the
server encoding.
[EMAIL PROTECTED] (Tom Lane) writes:
Bruce Momjian [EMAIL PROTECTED] writes:
The big question is whether this is for 8.3 or 8.4.
What I would definitely like to see for 8.3 is some performance testing
done to determine whether we ought to change the current defaults.
(Both
Patch rejected, since we have decided we need to have this as part of
CREATE/ALTER table, rather than a GUC.
---
Chris Browne wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Simon Riggs [EMAIL PROTECTED] writes:
Well it
Simon Riggs wrote:
On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be such a good idea though, or at least it
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
What I would definitely like to see for 8.3 is some performance testing
done to determine whether we ought to change the current defaults.
(Both TOAST_TUPLES_PER_PAGE and EXTERN_TUPLES_PER_PAGE ought to be looked
at.)
75 matches
Mail list logo
