On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Where are we on this?
---
Tom Lane wrote:
>
> [squint...] How can that fail during a reload if it worked the first
> time? Needs a closer look at what's happening.
>
Not just EDB :-)
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Chris Browne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 04, 2007 10:07 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:Re: [HACKERS] Modifying TOAST thresholds
[EMAIL P
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 look
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
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:
> >> W
[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 TOAST_TUPL
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
>> >
"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 befor
"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
> 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 conv
> 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 whic
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 so
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
> o
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 driv
> Tatsuo Ishii wrote:
>
> > . 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. So
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 p
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
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 extre
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 kno
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
parti
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 va
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 _eve
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
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 acr
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 deci
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
> > >> cycle
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 e
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 h
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 p
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 partit
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 as
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 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?
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 opera
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 partition
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
includin
"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
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 ?
Why do we even need to support xpath on fragments?
Why not? I find it useful and convenient.
--
Be
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 po
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 t
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
ca
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.
>
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 firs
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,
Tatsuo Ishii wrote:
. 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 needs to
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.
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 un
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 frequently
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
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
> 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 l
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 U
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 appropri
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
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 multi-ta
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 m
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 valu
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 clien
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 (auto
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 t
"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, thou
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 t
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 particular point caught my
eye. If you'll f
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
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 separa
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
suppo
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.
Am
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 altern
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 XLo
> > 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 Orac
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, Simo
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 f
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 f
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
> 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,
> 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).
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
77 matches
Mail list logo
