On Mar 22, 2007, at 7:25 AM, Pavan Deolasee wrote:
Grzegorz, if you can try HOT as well, that will be great.
I tried, and it worked very well with 4.2 v of patch, as I remember.
My point was, since 'the day' comes closer, and you guys work on
close areas inside pg - I would like to be a
okay, I got it. The main reason behind it - is that I do drop table
in transaction. Every 10 minutes. So during that period, when
'replication' is running - the thing becomes unstable, and this error
can appear.
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---
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,
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
> 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
> > EU
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
> 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
> 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
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
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
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 groupi
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 import
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++
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 i
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 simp
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 s
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
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.p
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 l
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 th
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: don't
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
>
> Jos
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 the
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
> >
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
Pro
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 result
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
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, e.g
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 se
[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 MA
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 fall
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 inserts/u
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 MAXALIGN(sizeof(Pag
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 hea
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 c
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?
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 an
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
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 t
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
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 rat
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
>
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
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 res
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 * sizeof(Ite
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 i
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
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 result
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 -
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 th
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/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 t
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 fi
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
clusteredne
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 xi
"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.
> --
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 compl
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 tha
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 c
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
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 ans
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 tupl
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 ex
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
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 P&L side, the account that captures
>> exchange rate movements. But this i
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 P&L accounts
there is generally no change in exchange
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 ca
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.
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
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
>
>> 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-
"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 rel
"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
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 HO
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 p
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 P&L accounts
there is generally no change in exchange rates over time and yo
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
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
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.
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
"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
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 e
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.
group
[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
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
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
Josh Berkus 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 on a cou
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
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 P&L accounts
> th
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'Arc
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.
cheers
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"[
"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?
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-p
"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 tuple
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 sorti
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.
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 sid
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
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). ;-)
---
Dan
1 - 100 of 102 matches
Mail list logo
