Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked through the available
Dennis Bjorklund [EMAIL PROTECTED] writes:
What is the reason to keep it?
The words-of-one-syllable answer is that D'Arcy Cain is still willing
to put work into supporting the money type, and if it still gets the
job done for him then it probably gets the job done for some other
people
Sorry I forgot the attach :-)
It is not perfect so bear with me, it is my first try.
Regards,
D.
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
And the patch is so small, it is invisible (missing). ;-)
---
Dany
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Tom Lane skrev:
Whether it is actually ever going to disappear is not agreed upon.
What is the reason to keep it?
The words-of-one-syllable answer is that D'Arcy Cain is still willing
to put work into supporting the money type,
On Tue, 2007-03-20 at 18:12, Josh Berkus wrote:
Tom,
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that the FK relationship
exists, it would know that each row of the FK side joins to exactly
one row of the PK side, which
This should read:
Considering that the FK part is unique, the
^^PK^^
skewness in the relationship is completely determined by the FK part's
histogram. That would give at least a lower/upper bound and MCVs to the
relationship.
Cheers,
Csaba.
Joshua D. Drake wrote:
Hackers et al... I was wondering if there are any outstanding issues
that need to be resolved in terms of the clustered index/bitmap changes?
I have a todo list of smaller items for clustered indexes, but the main
design issues at the moment are:
1. How to handle
Heikki Linnakangas [EMAIL PROTECTED] writes:
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
On Tue, Mar 20, 2007 at 08:27:46PM -0400, Tom Lane wrote:
and of course if you multiply that by 6 you get
regression=# SELECT (10::numeric(2,0) / 6::numeric(2,0)) * 6;
?column?
-
10.0002
(1 row)
The only way to fix that is to shift from fixed-point
Tom Lane [EMAIL PROTECTED] writes:
but I wouldn't want to defend the details of the rule about how many
fractional digits out given so many fractional digits in.
In particular it seems to me this is poor:
postgres=# select 1::numeric/10;
?column?
Germán Poó Caamaño escribió:
I'm a student and I'm planning to submit a project for Google Summer of
Code. I would like to receive feedback about to implement the vacumm
scheduling in order to allow maintenance's windows.
I have read the whole discussion about Autovacuum improvements[1]
August Zajonc wrote:
The only other nice thing would be user defined precision, but
can live without that as most currencies work under nnn.mm.
That's useless for our system at least. The minimum scale we use for
money values is 5. I guess we can just continue to use numeric though.
On Wed, 21 Mar 2007 02:31:44 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Tom Lane skrev:
Whether it is actually ever going to disappear is not agreed upon.
What is the reason to keep it?
The words-of-one-syllable answer is that D'Arcy Cain is
On Wed, 21 Mar 2007 02:13:54 -0700
August Zajonc [EMAIL PROTECTED] wrote:
Agreed with Tom on this one. Full usage of money is beyond tagged types
etc. For example, when you earn money in another currency, it is the
time at which you earn it that describes its value. So for PL accounts
there is
Bruce Momjian wrote:
I have read the HOT discussion and wanted to give my input. The major
issue is that CREATE INDEX might require a HOT chain to be split apart
if one of the new indexed columns changed in the HOT chain.
To expand a little more, the problem is that when you split those HOT
Josh Berkus josh@agliodbs.com writes:
Tom Lane wrote:
sql_inheritance is a little bit
bigger deal, but I wonder whether we shouldn't just remove that variable
altogether --- it's been default ON since 7.1 and I've not heard anyone
complain about that in a long time.
Let's do a quick survey
Hello,
Following Tom's lead... should we also remove this? We have had it for a
couple of releases, and really all we are doing is protecting the use of
bad queries.
Can we remove it?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564
Bruce Momjian 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 doing lookups using that index, the
[EMAIL PROTECTED] (Magnus Hagander) writes:
Native shared memory implementation for win32.
Uses same underlying tech as before, but not the sysv emulation layer.
Actually, I was wondering whether the cygwin port could use this new
code too, so that we could get rid of the __CYGWIN__ kluges in
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
suggest to enable stats_block_level to see the effect on buffer
cache hit/miss ratio.
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the effect on buffer
Joshua D. Drake [EMAIL PROTECTED] writes:
Following Tom's lead... should we also remove this? We have had it for a
couple of releases, and really all we are doing is protecting the use of
bad queries.
No, AFAICT it's still in active use --- you need not look back far in
the mailing lists to
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Following Tom's lead... should we also remove this? We have had it for a
couple of releases, and really all we are doing is protecting the use of
bad queries.
No, AFAICT it's still in active use --- you need not look back far in
the
On Wed, 2007-03-21 at 10:47 -0400, Bruce Momjian 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.
On Wed, Mar 21, 2007 at 11:15:46AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] (Magnus Hagander) writes:
Native shared memory implementation for win32.
Uses same underlying tech as before, but not the sysv emulation layer.
Actually, I was wondering whether the cygwin port could use this new
Andrew Dunstan wrote:
August Zajonc wrote:
The only other nice thing would be user defined precision, but
can live without that as most currencies work under nnn.mm.
That's useless for our system at least. The minimum scale we use for
money values is 5. I guess we can just continue to use
August Zajonc wrote:
Agreed with Tom on this one. Full usage of money is beyond tagged types
etc. For example, when you earn money in another currency, it is the
time at which you earn it that describes its value. So for PL accounts
there is generally no change in exchange rates over time and
Sorry, I was a bit too quick to respond. I didn't understand at first
how this differs from Pavan's/Simon's proposals.
Let me answer my own questions.
Heikki Linnakangas wrote:
Bruce Momjian wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in
On Wed, 2007-03-21 at 11:27 +0530, Pavan Deolasee wrote:
The version 5.0 of HOT WIP patch is posted on pgsql-patches. This
fixes the VACUUM FULL issue with HOT. In all the earlier versions,
I'd disabled VACUUM FULL.
When we move the HOT-chain, we move the chains but don't carry
the
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, AFAICT it's still in active use --- you need not look back far in
the mailing lists to find questions answered by see add_missing_from.
Oh, I know it is still in use, that is my complaint :). Perhaps stating
that this will be the
Bruce Momjian [EMAIL PROTECTED] writes:
We also add a boolean to pg_class to indicate no new HOT chains should be
created and set that to false once the new index is created.
Since we have all the index info in the relcache we could just skim through
all the indexes when we build the relcache
Oh, I know it is still in use, that is my complaint :). Perhaps stating
that this will be the last release of the feature?
Stating it doesn't make it so ;-)
O.k. that is certainly true :)
If we remove add_missing_from then some people will be unable to migrate
forward from pre-8.1
On 3/21/07, Simon Riggs [EMAIL PROTECTED] wrote:
It should do this, but its probably worth posting a TODO of minor items
like this, otherwise we'll lose focus on the major items.
Well, I didn't add anything new here. VACUUM validates the
number of index entries and heap entries. With HOT I
is there an existing mechanism to do user based connection controls in
Postgres 7.4?
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Heikki Linnakangas wrote:
Bruce Momjian 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
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the effect on buffer
Shane Ambler wrote:
August Zajonc wrote:
Agreed with Tom on this one. Full usage of money is beyond tagged types
etc. For example, when you earn money in another currency, it is the
time at which you earn it that describes its value. So for PL accounts
there is generally no change in exchange
Shane Ambler wrote:
August Zajonc wrote:
For balance sheet accounts, their value at a given point in time in a
home currency is of course dependent on exchange rates which creates the
currency gain or loss on the PL side, the account that captures
exchange rate movements. But this is
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
I have read the HOT discussion and wanted to give my input. The major
issue is that CREATE INDEX might require a HOT chain to be split apart
if one of the new indexed columns changed in the HOT chain.
To expand a
Simon Riggs wrote:
On Wed, 2007-03-21 at 10:47 -0400, Bruce Momjian 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
Ah, sounds like you have the idea clearly now. Great.
---
Heikki Linnakangas wrote:
Sorry, I was a bit too quick to respond. I didn't understand at first
how this differs from Pavan's/Simon's proposals.
Let me answer
As stated in later email, I think we should focus on the xid idea
because it is more flexible.
---
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We also add a boolean to pg_class to indicate no new HOT
Pavan Deolasee wrote:
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
I have read the HOT discussion and wanted to give my input. The major
issue is that CREATE INDEX might require a HOT chain to be split apart
if one of the new indexed columns changed in
In some of our applications, we have cases where it would be very nice
if we could activate TOAST at some sort of lower threshold than the
usual 2K that is true now. Let me note the current code that controls
the threshold:
/*
* These symbols control toaster activation. If a tuple is larger
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I am worried that will require CREATE INDEX to wait for a long time.
Not unless there are long running transactions. We are not waiting
for the lock, but only for the current transactions to finish.
Is the pg_index xid idea too
Bruce Momjian [EMAIL PROTECTED] writes:
As stated in later email, I think we should focus on the xid idea
because it is more flexible.
Sorry if I was unclear. I agree, my comment and questions are all predicated
on the assumption that we would go with xids.
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As stated in later email, I think we should focus on the xid idea
because it is more flexible.
Sorry if I was unclear. I agree, my comment and questions are all predicated
on the assumption that we would go with xids.
OK,
Joshua D. Drake wrote:
Right. My understanding is that the clustered index will gradually
degrade to a normal btree, is that correct heikki?
That's right.
We could of course resolve this by doing a reindex.
Not reindex, but cluster. How clustered the index can be depends on the
Pavan Deolasee wrote:
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I am worried that will require CREATE INDEX to wait for a long time.
Not unless there are long running transactions. We are not waiting
for the lock, but only for the current transactions to finish.
Waiting
Hi,
If you are looking for a SoC idea, I have listed a couple below. I
am not sure how good of an idea they are but I have ran into the
following limitations and probably other people have as well in the
past.
1. Can user based priorities be implemented as a summer project? To
some
On 3/20/2007 1:11 PM, Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked
Effectively, my idea is not to chill/break the HOT chains during index
creation, but rather to abandon them and wait for VACUUM to clean them
up.
My idea is much closer to the idea of a bit per index on every tuple,
except the tuple xmax and pg_index xid replace them.
On 3/21/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
It seems much simpler to me do something like this. But important
question is whether the restriction that CREATE INDEX can not
be run in a transaction block is acceptable ?
yikes -- this is huge, huge price to pay, IMHO. Think about DDL
On 3/21/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 3/21/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
It seems much simpler to me do something like this. But important
question is whether the restriction that CREATE INDEX can not
be run in a transaction block is acceptable ?
yikes -- this
Jan Wieck [EMAIL PROTECTED] writes:
On 3/20/2007 1:11 PM, Tom Lane wrote:
search_path
add_missing_from
transform_null_equals
sql_inheritance
Don't we actually store the parsetree in the query cache, and doesn't
that actually make a lot of the above rather NOT affect the resulting
plan
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Effectively, my idea is not to chill/break the HOT chains during index
creation, but rather to abandon them and wait for VACUUM to clean them
up.
My idea is much closer to the idea of a bit per index on every tuple,
except the tuple xmax and
Pavan Deolasee wrote:
On 3/21/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 3/21/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
It seems much simpler to me do something like this. But important
question is whether the restriction that CREATE INDEX can not
be run in a transaction block is
Chris Browne [EMAIL PROTECTED] writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from
TOAST_DENOMINATOR = 4 */
#define TOAST_TUPLE_THRESHOLD^I\
^IMAXALIGN_DOWN((BLCKSZ - \
^I^I^I^I MAXALIGN(sizeof(PageHeaderData) + 3 *
On 3/21/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
On 3/21/07, Merlin Moncure [EMAIL PROTECTED] wrote:
On 3/21/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
It seems much simpler to me do something like this. But important
question is whether the restriction that
Pavan Deolasee wrote:
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Effectively, my idea is not to chill/break the HOT chains during index
creation, but rather to abandon them and wait for VACUUM to clean them
up.
My idea is much closer to the idea of a bit per index on every
Bruce Momjian wrote:
Also, I am wondering whether the information that which index is used to
fetch a tuple is always available. I haven't checked, but do we have that
information in lossy bitmap heapscan ?
Oh, that is an interesting problem because an index might have one index
entry
On 3/21/2007 1:46 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 3/20/2007 1:11 PM, Tom Lane wrote:
search_path
add_missing_from
transform_null_equals
sql_inheritance
Don't we actually store the parsetree in the query cache, and doesn't
that actually make a lot of the above
Bruce Momjian wrote:
Bruce Momjian wrote:
Also, I am wondering whether the information that which index is used to
fetch a tuple is always available. I haven't checked, but do we have that
information in lossy bitmap heapscan ?
Oh, that is an interesting problem because an index
On Mar 21, 2007, at 5:22 PM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
suggest
On Wed, 2007-03-21 at 13:29 -0400, Bruce Momjian wrote:
Pavan Deolasee wrote:
On 3/21/07, Bruce Momjian [EMAIL PROTECTED] wrote:
I am worried that will require CREATE INDEX to wait for a long time.
Not unless there are long running transactions. We are not waiting
for
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Also, I am wondering whether the information that which index is used to
fetch a tuple is always available. I haven't checked, but do we have that
information in lossy bitmap heapscan ?
Oh, that is an interesting problem because
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Grzegorz Jaskiewicz wrote:
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
I've run tests with both patches applied. I haven't tried with the
latest HOT-versions, but they should in theory work fine together.
You'll get a
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Also, I am wondering whether the information that which index is used to
fetch a tuple is always available. I haven't checked, but do we have that
information in lossy bitmap heapscan ?
Oh, that
On 3/21/2007 2:05 PM, Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from TOAST_DENOMINATOR = 4 */
#define TOAST_TUPLE_THRESHOLD^I\
^IMAXALIGN_DOWN((BLCKSZ - \
^I^I^I^I
I got :
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still
in use
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still
in use
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still
in use
on 8.1.8 my production server here.
some
Is this a TODO?
---
Jan Wieck wrote:
On 3/21/2007 2:05 PM, Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from
[EMAIL PROTECTED] (Tom Lane) writes:
Chris Browne [EMAIL PROTECTED] writes:
#define TOAST_DENOMINATOR 17
/* Use this as the divisor; current default behaviour falls from
TOAST_DENOMINATOR = 4 */
#define TOAST_TUPLE_THRESHOLD^I\
^IMAXALIGN_DOWN((BLCKSZ - \
^I^I^I^I
Grzegorz Jaskiewicz wrote:
I got :
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still in
use
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still in
use
2007-03-21 20:56:17 CET ERROR: relation 71478240 deleted while still in
use
on 8.1.8 my production
Here is the full TODO item:
* Add NUMERIC division operator that doesn't round?
Currently NUMERIC _rounds_ the result to the specified precision.
This means division can return a result that multiplied by the
divisor is greater than the dividend,
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
---
Tom Lane wrote:
I wrote:
I'm not sure if this
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support. I see it's been discussed in the
past ( e.g.
http://archives.postgresql.org/pgsql-interfaces/2000-09/msg00082.php ).
We have occasional reports of libpq apps blowing up on huge
You can now checkout a pgsql converted to svn repo here:
http://projects.commandprompt.com/public/pgsql/repo/
It updates every four hours or so.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Bruce Momjian wrote:
You don't need to scan the whole page like in the lossy bitmap mode,
just all the tuples in the HOT-chain.
You need to somehow pass the information that multiple indexes have been
used in the bitmap scan to the bitmap heapscan node, so that it knows
when the
I guess this matches this TODO item:
o Allow selection of individual object(s) of all types, not just
tables
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
Joshua D. Drake wrote:
You can now checkout a pgsql converted to svn repo here:
http://projects.commandprompt.com/public/pgsql/repo/
It updates every four hours or so.
You can access thusly:
svn co --username anonymous
http://projects.commandprompt.com/public/pgsql/repo pg
Joshua D.
Bruce Momjian wrote:
Anyway, perhaps we can leave the bitmap scan part to someone more
familiar with that part of the code, like Tom.
Yeah. We all know he doesn't have enough to do ...
cheers
andrew
---(end of broadcast)---
TIP 5:
On Wed, Mar 21, 2007 at 12:37:36PM -0400, Chris Browne wrote:
4. A different mechanism would be to add a fifth storage column
strategy (the present four are PLAIN, EXTENDED, EXTERNAL, MAIN), let's
say, TOAST.
At present, the 4 values are essentially advisory; columns get TOASTed
if the
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
should I add it as a bug ?
Only if you can reproduce it in 8.2 --- what it looks like to me is a
relcache-opening race condition, which is (believed) fixed in 8.2 and
is not feasible to fix in older branches.
regards, tom
On Wed, Mar 21, 2007 at 05:32:21PM -0400, Andrew Dunstan wrote:
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support. I see it's been discussed in the
past ( e.g.
http://archives.postgresql.org/pgsql-interfaces/2000-09/msg00082.php
Andrew Dunstan [EMAIL PROTECTED] writes:
I was looking at the TODO list today and noticed that we don't seem to
have an item for libpq cursor support.
I doubt that cursor support is what you want, but rather access to the
partial-fetch capability of extended query protocol. But that's an
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
Well, it's a subset of it, but do we want to accept a patch that's been
designed with only a subset in mind? I'd like to see a
Hi,
While coding the autovacuum stuff I noticed that the dllist.c doubly
linked list infrastructure is using malloc(). And the failure cases are
handled in #ifdef FRONTEND exit(1) #else elog(ERROR) #endif.
This seems a bit ugly, but more importantly, it doesn't let me free the
whole list by
Tom Lane 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
Well, it's a subset of it, but do we want to accept a patch that's been
designed with only a subset in
On Mar 21, 2007, at 11:25 PM, Tom Lane wrote:
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
should I add it as a bug ?
Only if you can reproduce it in 8.2
okie dokie, I am moving the DB onto 8.2 next week (120M of rows, and
8.2 does sorting much faster).
--
Grzegorz Jaskiewicz
C/C++
Alvaro Herrera [EMAIL PROTECTED] writes:
Hi,
While coding the autovacuum stuff I noticed that the dllist.c doubly
linked list infrastructure is using malloc(). And the failure cases are
handled in #ifdef FRONTEND exit(1) #else elog(ERROR) #endif.
This seems a bit ugly, but more importantly,
Ah, so you wait for me to go on vacation to apply it! Well, I am back
now, buddy. ;-)
One thing that bothers me about the patch is that it seems you are
adding functionality that allows you to enable/disable trigger firing in
groups, which is fine, but you are hard-coding the use of that
Hi,
I would like to propose adding new character set JIS X
0213(http://en.wikipedia.org/wiki/JIS_X_0213).
JIS X 0213 is a relatively new Japanese goverment standard (defined in
2000, revised in 2004), and becomes important for Japanese
users. Moreover some commercial OSs including Windows VISTA
Tatsuo Ishii [EMAIL PROTECTED] writes:
I would like to propose adding new character set JIS X
0213(http://en.wikipedia.org/wiki/JIS_X_0213).
...
Note that since encoding schema of EUC_JIS_2004 is exactly identical
to EUC_JP, we can reuse existing encoding routines defined in
utls/mb/*.c.
Tatsuo Ishii [EMAIL PROTECTED] writes:
I would like to propose adding new character set JIS X
0213(http://en.wikipedia.org/wiki/JIS_X_0213).
...
Note that since encoding schema of EUC_JIS_2004 is exactly identical
to EUC_JP, we can reuse existing encoding routines defined in
Tatsuo Ishii [EMAIL PROTECTED] writes:
I would like to propose adding new character set JIS X
0213(http://en.wikipedia.org/wiki/JIS_X_0213).
...
Note that since encoding schema of EUC_JIS_2004 is exactly identical
to EUC_JP, we can reuse existing encoding routines defined in
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm confused. If this is exactly the same as EUC_JP, why do we need
any new code at all?
I said *encoding schema is same, not the contents (character set) is
same. In another word, characters included in EUC_JP are not same as
EUC_JIS_2004.
I'm still
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm confused. If this is exactly the same as EUC_JP, why do we need
any new code at all?
I said *encoding schema is same, not the contents (character set) is
same. In another word, characters included in EUC_JP are not same as
EUC_JIS_2004.
On 3/22/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Grzegorz Jaskiewicz wrote:
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
I've run tests with both patches applied. I haven't tried with the
latest HOT-versions, but
Hello,
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_max_length() == 1 test. I'll propose to extend
100 matches
Mail list logo
