Tom Lane wrote:
> Ugh. So given that linker behavior, it's basically impossible to
> support multiple libpq versions in the same directory anyway on AIX.
It is possible, if you have both versions of the shared object in
the same library. Essentially what I proposed for 3b).
It is the way IBM does
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I do :) Writing the scripts up are easy enough, but I am unsure how
> the whole make file foo works...
About all you have to do is add the uninstall script to the "DATA = "
line in the makefile.
regards, tom lane
-
Then there is the problem that we need consistent wording through the
release notes, so again, I have to wack around some more text.
I think this is a strange objection. Many different people have
contributed to the documentation, and yet we've managed to keep the
wording reasonably consiste
Guido Barosio wrote:
Let me know if you need an extra pair of eyes.
O.k. I do :) Writing the scripts up are easy enough, but I am unsure how
the whole make file foo works...
Joshua D. Drake
G.-
On 9/10/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
> "Joshua D. Drake" <
On Thu, 14 Sep 2006, Joshua D. Drake wrote:
Well on that same vein (with a +1), I know that we lost at least 8 weeks
of productivity from various vacations etc.. during the summer. When you
incorporate everyone else that is involved with postgresql, I could
easily see almost a full man year lo
On Thursday 14 September 2006 17:36, Joshua D. Drake wrote:
> But on a serious note, the problem I run into is exactly the opposite.
> Someone will turn on autovacuum because they thought it was a good idea
> and for their work load, it isn't. So instead of creating new and
> interesting ways to al
On Thursday 14 September 2006 14:16, Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > Point I want to make is - all those are cool features(and might be
> > critical for some) but I don't think they warrant a dramatic change in
> > the release cycle policy ...
>
> Any release
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
> Leaving autovacuum on will cement the idea that it *should* be on and
> IMHO it shouldn't without specific and careful planning.
For the "completely naive user," it seems to me that it *should* be
on, as that will diminish the number of questions tha
Suppose there are too tuples in a table t, named
id
---
1
2
and there is a unique index on id. Now we do an update on table t
update t set id=id+1
Since PG executes the update one tuple at a time, it updates tuple "1"
to "2" and insert it into the index. Before insert into the index, it
check wh
> Mark Wong <[EMAIL PROTECTED]> writes:
>> Curious, I'm still seeing the same behavior. Maybe I'll take another
>> snapshot from CVS.
>
> Hm, maybe I need to try a bit harder here. Does the "not registered"
> error happen immediately/reliably for you, or do you need to run the
> test awhile?
It
Done.
---
Joe Conway wrote:
> Bruce Momjian wrote:
> > Here is an early draft of the release notes. It needs more polish and
> > review:
> >
> > http://momjian.us/cgi-bin/pgrelease
> >
> > I will catch up on my email
Jeff Davis <[EMAIL PROTECTED]> writes:
> Couldn't you just sort by the table names, and ANALYZE the tables in
> that order? Would that effectively prevent the deadlocks?
That'd work too, I think (I suggested the variant of ordering by OID,
which is simpler and more reliable). Not sure if it's rea
Mark Wong <[EMAIL PROTECTED]> writes:
> Curious, I'm still seeing the same behavior. Maybe I'll take another
> snapshot from CVS.
Hm, maybe I need to try a bit harder here. Does the "not registered"
error happen immediately/reliably for you, or do you need to run the
test awhile?
> As for the
On Thu, 2006-09-14 at 18:25 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > How would creating a new lock type avoid deadlocks when an ANALYZE is
> > accumulating the locks in random order?
>
> In itself it wouldn't. Josh Drake sketched the idea in more detail
> later: if ther
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > How is maintaining another file on every commit going to go over?
>
> If memory serves, we tried this before --- back in the 7.4 devel cycle,
> people were supposed to add small entries to release.sgml every time
> they committed some
Bruce Momjian <[EMAIL PROTECTED]> writes:
> How is maintaining another file on every commit going to go over?
If memory serves, we tried this before --- back in the 7.4 devel cycle,
people were supposed to add small entries to release.sgml every time
they committed something worth mentioning in th
Also, personally, I would rather do it all at once rather than
throughout the development cycle. It is like moving 100 potatoes one at
a time compared to placing them in a sack and moving them all at once.
Also, we are having trouble getting enough people to review/commit.
Does adding an extra
Jeff Davis <[EMAIL PROTECTED]> writes:
> How would creating a new lock type avoid deadlocks when an ANALYZE is
> accumulating the locks in random order?
In itself it wouldn't. Josh Drake sketched the idea in more detail
later: if there is a lock type used *only* for ANALYZE, then you can do
Condi
The only win to doing this incrementally is that people will have some
idea of what is the release before I create the list just before beta.
This will probably save me only minimal amount of time compared to the
extra work it will require of everyone. Also consider patches on top of
patches are
I wrote:
> If you're really intent on making it work this way, my vote is to
> expose namespace.c's isOtherTempNamespace() as a SQL-callable function,
> and add a test on that to the info-schema views, rather than relying on
> is_visible or explicit knowledge of the temp-schema naming convention.
Bruce Momjian wrote:
There are problems with this.
There are going to be problems with just about any proposal, but I think
updating the release notes incrementally is still a clear net win.
First, since everyone isn't going to do it, I still have to go
through all the CVS logs, and then I
On Thu, 2006-09-14 at 11:20 -0400, Tom Lane wrote:
> andy <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> andy <[EMAIL PROTECTED]> writes:
> This behavior dates from a time when there was no good alternative.
> One possible fix today would be to make ANALYZE take
> ShareUpdateExclusive lock in
On Thu, Sep 14, 2006 at 10:21:30PM +0100, Gregory Stark wrote:
> >> One very nifty trick would be to fix "char" to act as CHAR(), and map
> >> CHAR(1) automatically to "char".
> > Sorry, probably a stupid idea considering multi-byte encodings. I
> > suppose it could be an optimization for single-b
Alvaro Herrera wrote:
Joshua D. Drake wrote:
No one would expect Oracle to install Oracle and walk away. We are not
MySQL, nor MS Access.
Then why are you complaining about having to disable autovacuum after
each installation?
Because my hands hurt and I can't find my gloves. My back hurts (
I would like the ability to absolutely set parameters/settings in psql
so that our psql scripts could generate predictable output absent a
known or controllable initial state. Original discussion at bottom of
message.
One alternate and easier approach I've thought of is to simply add
something aki
Tom Dunstan wrote:
Joshua D. Drake wrote:
No one would expect Oracle to install Oracle and walk away. We are not
MySQL, nor MS Access.
And thank goodness for that!
Hah! I knew you would eventually agree with me. ;)
Joshua D. Drake
Tom
---(end of broadcast)
Gevik Babakhani wrote:
> As suggested in earlier discussion we provide a raw/plain output of
> the uuid type:
>
> devdb=# select * from tbluuid;
> pk|
> --+
> 6b13c5a1afb4dcf5ce8f8b4656b6c93c |
> 01e40a79b55b6e226bffb577e960453d |
>
Joshua D. Drake wrote:
No one would expect Oracle to install Oracle and walk away. We are not
MySQL, nor MS Access.
And thank goodness for that!
Tom
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> My memory says this was eventually removed, even though it was committed
> >> for a time. Am I wrong?
> >> - Make EXPLAIN sampling smarter, to avoid excessive sampling delay
> >> (Martijn van Oosterhout)
>
> >
Joshua D. Drake wrote:
>
> No one would expect Oracle to install Oracle and walk away. We are not
> MySQL, nor MS Access.
Then why are you complaining about having to disable autovacuum after
each installation?
It may just be me, but I see as a lot easier to disable autovacuum than
to write the
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> One very nifty trick would be to fix "char" to act as CHAR(), and map
>> CHAR(1) automatically to "char".
>
> Sorry, probably a stupid idea considering multi-byte encodings. I
> suppose it could be an optimization for single-byte encodings, but that
>
No one would expect Oracle to install Oracle and walk away. We are not
MySQL, nor MS Access.
I can definitely see where you're coming from, it's a sort of tough-love
scenario. There are legitimate counter arguments, though. The most
obvious is that anyone who *does* evaluate their needs pro
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> My memory says this was eventually removed, even though it was committed
>> for a time. Am I wrong?
>> - Make EXPLAIN sampling smarter, to avoid excessive sampling delay
>> (Martijn van Oosterhout)
> I see a reversion for EXPLAIN AN
Gevik,
> select format_uuid(mypk,'format3') from tbluuid;
> and then get: {6b13c5a1-afb4-dcf5-ce8f-8b4656b6c93c}
> (which would be MSSQL compatible)
> What do the PostgreSQL masters think? :)
There are no masters here. Except in replication.
I think that we should have a formatting function,
Simon Riggs wrote:
> On Thu, 2006-09-14 at 01:12 -0400, Bruce Momjian wrote:
> > Here is an early draft of the release notes. It needs more polish and
> > review:
> >
> > http://momjian.us/cgi-bin/pgrelease
> >
> > I will catch up on my email tomorrow, update the open items list for
> > 8.2,
Darcy,
> The biggest argument about the money type is that it has an unrealistic
> limit.
Funny, I thought it was the lack of operators, conversions and any clear plan
on how to have a money type that supports multiple currencies.
Or are you working on those? That would be keen ...
--
Josh
On 9/14/06, Gevik Babakhani <[EMAIL PROTECTED]> wrote:
At this moment we (almost) have a uuid/guid datatype.
As suggested in earlier discussion we provide a raw/plain output of the
uuid type:
devdb=# select * from tbluuid;
pk|
--+
OK, removed.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> Store only active XIDs in subtransaction cache
> >>
> >> Per my note just now, this probably should wait for 8.3.
>
> >
OK, all updated. Thanks.
---
Sergey E. Koposov wrote:
> The list of functions for:
> * Add SQL2003-standard statistical aggregates (Sergey Koposov)
>
> regr_intercept, regr_slope, regr_r2, corr, covar_samp, covar_pop,
> r
Magnus Hagander wrote:
> >Here is an early draft of the release notes. It needs more polish and
> >review:
> >
> > http://momjian.us/cgi-bin/pgrelease
> >
> >I will catch up on my email tomorrow, update the open items list for
> >8.2, and then return to the release notes for cleanup.
>
> * Al
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Store only active XIDs in subtransaction cache
>>
>> Per my note just now, this probably should wait for 8.3.
> OK, added to TODO.
Actually, I realized this morning that there isn't anything there that
the current code doesn't do al
Great. Added:
http://momjian.postgresql.org/cgi-bin/pgrelease
---
Teodor Sigaev wrote:
> * Improve multicolumn GiST index (oleg,teodor)
> * GiST indexes now are clusterable (teodor)
> * tsearch2 improvements (oleg,
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> One possible fix today would be to make ANALYZE take
>> ShareUpdateExclusive lock instead, thus ensuring there is only one
>> ANALYZE at a time on a table.
> Why not an internal lock that people don't see?
We could add another LockTagType just for
Guillaume Smet wrote:
> On 9/14/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Here is an early draft of the release notes. It needs more polish and
> > review:
> >
> > http://momjian.us/cgi-bin/pgrelease
>
> AFAICS the log_duration behaviour change made by Tom a few days ago is
> not t
Hannu Krosing wrote:
> ?hel kenal p?eval, N, 2006-09-14 kell 01:12, kirjutas Bruce Momjian:
> > Here is an early draft of the release notes. It needs more polish and
> > review:
> >
> > http://momjian.us/cgi-bin/pgrelease
> >
> > I will catch up on my email tomorrow, update the open items li
Tom Lane wrote:
> There are several entries on the 8.2 open-items list that I think can be
> removed:
>
> Fix backward array comparison - subset
>
> Done (this was redundant with the containment-operator item)
OK, that wasn't clear to me.
> Store only active XIDs in subtransaction c
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Robert Treat wrote:
> > > On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
> > > > Andrew Dunstan wrote:
> > > > > Bruce Momjian wrote:
> > > > > > I again will not be able to complete the release notes today as
> > > > > > promised. My next
Stefan Kaltenbrunner wrote:
Interesting idea but we already have one of the fastest release cycles
of all database systems and some people would like to see a larger cycle.
I think the key complaint is about how painful the upgrade process is
and if you still get fixes for previous releases i
Christopher Browne wrote:
> Seems to me that what I mostly do is print off a copy, show how thick
> it is, and say "There are a really a lot of things improved, as
> visible on this list; alas, few are obviously 'sexy' new things..."
Think "marshmallow explosion". Lots of white, fluffy stuff ever
On Tue, Aug 29, 2006 at 02:36:21PM +0200, Michael Meskes wrote:
[Various ECPG connection string problems.]
> Fixed.
Are any of these changes considered bug fixes that will be backpatched,
or should I prepare different documentation patches for different
versions? With the recent talk about releas
Tom Lane wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
> > On 9/13/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> statement: querystring Simple Query
> >> parse : querystring Parse
> >> bind /: querystring Bind
> >> execute /: querystringExecute
>
> >
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> w00t, more processes doing things they shouldn't be doing, but doing
> them automatically at times when they shouldn't be done because of some
> arbitrary calculation that really isn't documented that well in some
> conf file!
I'd love for it to be
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Naz Gassiep wrote:
> >> Did this make it into the to-do list for 8.3 ?
>
> > Don't worry about the to-do list too much.
>
> In particular, if you're imagining that being in the TODO list will
> in itself cause anyone to work on it,
O.k. that was negative, sorry. Frankly I think that turning autovacuum
on by default pretty much equates to, "I am lazy, and I don't want to
actually evaluate my needs. Lets just go with MS Access"
Please ignore my negativity today. I apologize. I do not want autovacuum
turned on by default
Quite a few people (myself included) had really been hoping to see it in
8.2 and it's been the going-forward plan ever since autovacuum was put
into the backend (in fact, iirc, having it in the backend was a
prerequisite to having it on by default).
w00t, more processes doing things they should
OK, removed from open item list.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've applied this but I'm now having some second thoughts about it,
> >> because I'm seeing an actual
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> >* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> >>Updateable views
> >>Bitmap indexes
> >>Recursive queries
> >>
> >>We would release in June?
> >
> >Could we get autovacuum enabled by default too?
>
> I certainly hope not... I
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
With that change, I didn't see run_workload report any errors, but maybe
I don't know where to look.
The error is captured in dbt2/scripts/output/*/client/error.log, where *
is the run directory.
Hm ... here's what I see
Mark Wong <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> With that change, I didn't see run_workload report any errors, but maybe
>> I don't know where to look.
> The error is captured in dbt2/scripts/output/*/client/error.log, where *
> is the run directory.
Hm ... here's what I see in there:
Stephen Frost wrote:
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
Updateable views
Bitmap indexes
Recursive queries
We would release in June?
Could we get autovacuum enabled by default too?
I certainly hope not... I don't really feel like turning it off all the
time.
Joshua D. Drake
* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> Updateable views
> Bitmap indexes
> Recursive queries
>
> We would release in June?
Could we get autovacuum enabled by default too?
Thanks,
Stephen
signature.asc
Description: Digital signature
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Oops! 'autoreconf --install' is what I run to generate all that stuff.
Ah, better. I see at least part of the problem:
CREATE OR REPLACE FUNCTION stock_level (INTEGER, INTEGER, INTEGER) RETURNS
INTEGER AS
'/home/tgl/dbt2/storedproc/pgs
Peter Eisentraut wrote:
> For those who don't read all the threads, I'll repeat it here. I've put
> up a wiki page working out the mysterious "XML support":
>
> http://developer.postgresql.org/index.php/XML_Support
>
> This is pretty much my talk from the conference.
>
> The short status is th
Mark Wong <[EMAIL PROTECTED]> writes:
> Oops! 'autoreconf --install' is what I run to generate all that stuff.
Ah, better. I see at least part of the problem:
CREATE OR REPLACE FUNCTION stock_level (INTEGER, INTEGER, INTEGER) RETURNS
INTEGER AS
'/home/tgl/dbt2/storedproc/pgsql/c/../../../sto
* D'Arcy J.M. Cain (darcy@druid.net) wrote:
> The benefit of the money type is speed. Because internal operations
> are done on integers they can generally be handled by single CPU ops.
> My tests on the 64 bit version show 10% to 25% improvement over numeric
> for many operations.
Erm, the numer
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
But perhaps something much easier, using subversion:
mkdir /mnt/dbt2 # for pgdata
svn co https://svn.sourceforge.net/svnroot/osdldbt/trunk/dbt2 dbt2
cd dbt2
./configure --with-postgresql=
configure is not in the svn checkout. I guessed
Mark Wong <[EMAIL PROTECTED]> writes:
> But perhaps something much easier, using subversion:
> mkdir /mnt/dbt2 # for pgdata
> svn co https://svn.sourceforge.net/svnroot/osdldbt/trunk/dbt2 dbt2
> cd dbt2
> ./configure --with-postgresql=
configure is not in the svn checkout. I guessed that I neede
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This is a server-side failure --- could we see how order_status()
is defined? What PG version are you testing exactly?
I took pgsqsl snapshot from cvs on Sept 11. Due to the length of the
file that order_status() is in a
Mark Wong <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is a server-side failure --- could we see how order_status()
>> is defined? What PG version are you testing exactly?
> I took pgsqsl snapshot from cvs on Sept 11. Due to the length of the
> file that order_status() is in and of ord
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Point I want to make is - all those are cool features(and might be
critical for some) but I don't think they warrant a dramatic change in
the release cycle policy ...
Any release is going to have some things that are compelling a
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Point I want to make is - all those are cool features(and might be
>> critical for some) but I don't think they warrant a dramatic change in
>> the release cycle policy ...
>
> Any release is going to have some things that are c
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Point I want to make is - all those are cool features(and might be
> critical for some) but I don't think they warrant a dramatic change in
> the release cycle policy ...
Any release is going to have some things that are compelling and some
that a
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Sorry for the delay but looks like there's some data coming in. It also
looks like my kit is starting to be a little dated. My stored libpq
calls are failing. I'm getting this message:
ERROR: record type has not been registered
This
On Sep 14, 2006, at 14:04 , D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 10:33:19 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
By the way, I removed the currency symbol from the output. Would
removing the commas also make sense? These are the sorts of things
that can be added by applica
URL added to TODO list.
---
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Even more interesting would be to fix things so that xml2 gets built
> > as part of the regular contrib build, but I'm not sure if we're ready
> > to
Mark Wong <[EMAIL PROTECTED]> writes:
> Sorry for the delay but looks like there's some data coming in. It also
> looks like my kit is starting to be a little dated. My stored libpq
> calls are failing. I'm getting this message:
> ERROR: record type has not been registered
This is a server-
On Thu, 14 Sep 2006 10:33:19 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > By the way, I removed the currency symbol from the output. Would
> > removing the commas also make sense? These are the sorts of things
> > that can be added by applications.
>
> I don't think that we should be p
Bruce Momjian wrote:
> Gregory Stark wrote:
> >
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >
> > > Gregory Stark wrote:
> > >>
> > >> Well "char" doesn't have quite the same semantics as CHAR(1). If that's
> > >> the
> > >> consensus though then I can work on either fixing "char" semantic
D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 08:17:29 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
Obviously ;), but it is deprecated by the project.
I keep hearing that but no action is ever taken. I think that there
are too many people who still find it useful.
By the way, I removed t
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
It would be nice to see some results from the OSDL tests with, say, 4,
8, and 16 lock partitions before we forget about the point though.
Anybody know whether OSDL is in a position to run tests for us?
Yeah, I can run some
On Thu, 14 Sep 2006 08:17:29 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Obviously ;), but it is deprecated by the project.
I keep hearing that but no action is ever taken. I think that there
are too many people who still find it useful.
By the way, I removed the currency symbol from th
Bruce Momjian wrote:
Here is an early draft of the release notes. It needs more polish and
review:
http://momjian.us/cgi-bin/pgrelease
I will catch up on my email tomorrow, update the open items list for
8.2, and then return to the release notes for cleanup.
Add support for Windows
Joshua D. Drake wrote:
>
In addition to that this plan might hold back some people from
upgrading
to 8.2 which solves quite a few critical issues with features we
marketed/introduced during the past 8.x cycles and are really getting
polished and usable now (partitioning,pi
In addition to that this plan might hold back some people from upgrading
to 8.2 which solves quite a few critical issues with features we
marketed/introduced during the past 8.x cycles and are really getting
polished and usable now (partitioning,pitr,...) and 8.2 gives quite a
nice performance b
Joshua D. Drake wrote:
> Stefan Kaltenbrunner wrote:
>> Joshua D. Drake wrote:
>>> Hello,
>>>
>>> I know that this would be completely out of the norm. However, would it
>>> be worth considering having a mid cycle release for 8.3?
>>>
>>> Basically the release would focus on:
>>>
>>> Updateable vie
My apologies if you are seeing this twice. I posted it last night, but
it still does not appear to have made it to the group.
Mark Dilger wrote:
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Please provide a stack trace --- AFAIK there shouldn't be any reason
why
Stefan Kaltenbrunner wrote:
Joshua D. Drake wrote:
Hello,
I know that this would be completely out of the norm. However, would it
be worth considering having a mid cycle release for 8.3?
Basically the release would focus on:
Updateable views
Bitmap indexes
Recursive queries
We would release
Joshua D. Drake wrote:
> Hello,
>
> I know that this would be completely out of the norm. However, would it
> be worth considering having a mid cycle release for 8.3?
>
> Basically the release would focus on:
>
> Updateable views
> Bitmap indexes
> Recursive queries
>
> We would release in June
Hello,
I know that this would be completely out of the norm. However, would it
be worth considering having a mid cycle release for 8.3?
Basically the release would focus on:
Updateable views
Bitmap indexes
Recursive queries
We would release in June?
Sincerely,
Joshua D. Drake
--
=== T
Gregory Stark wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >>
> >> Well "char" doesn't have quite the same semantics as CHAR(1). If that's the
> >> consensus though then I can work on either fixing "char" semantics to match
> >> CHAR(1) or adding a separate
This behavior dates from a time when there was no good alternative.
One possible fix today would be to make ANALYZE take
ShareUpdateExclusive lock instead, thus ensuring there is only one
ANALYZE at a time on a table. However I'm a bit concerned by the
possibility that ANALYZE-inside-a-transact
> select format_uuid(mypk,'format2') from tbluuid;
> and then get: 6b13c5a1-afb4-dcf5-ce8f-8b4656b6c93c
How about instead of fixed formats, you allow a format string using the
diverse parts of the GUID a la time formatting functions ? Then
everybody can format it as they want.
Just an idea.
Chee
Tom,
Taking the 4 lock vs 8 lock partitions, 4 LockMgr lock partitions spent
a total of 652 seconds in lock management (acquiring/releasing) and 8
LockMgr lock partitions spent a total of 536 in lock management. This is
an improvement of 116 seconds, but the TPS didn't improve by much - only
a 1.2
Folks,
I would like to have your opinion on the following:
At this moment we (almost) have a uuid/guid datatype.
As suggested in earlier discussion we provide a raw/plain output of the
uuid type:
devdb=# select * from tbluuid;
pk|
-
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> --- and because the entries are surely added in increasing XID order,
>> such an array could be binary-searched.
> If they're only added if they write to disk then isn't it possible to add them
> out of order? St
andy <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> andy <[EMAIL PROTECTED]> writes:
>>> So I'm ok, but I tried it again, by dropping the database and re-running
>>> both scripts and got the same error again. So thought I'd offer a test
>>> case if there was interest.
>>
>> Absolutely. I've
D'Arcy J.M. Cain wrote:
On Thu, 14 Sep 2006 07:59:07 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
D'Arcy J.M. Cain wrote:
For years I have been promising that a 64 bit version of the money type
was on the way. Here it is. So far it compiles and I have done some
basic testing on it and i
Tom Lane <[EMAIL PROTECTED]> writes:
> --- and because the entries are surely added in increasing XID order,
> such an array could be binary-searched.
If they're only added if they write to disk then isn't it possible to add them
out of order? Start a child transaction, start a child of that on
On Thu, 14 Sep 2006 07:59:07 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> D'Arcy J.M. Cain wrote:
> > For years I have been promising that a 64 bit version of the money type
> > was on the way. Here it is. So far it compiles and I have done some
> > basic testing on it and it seems to wor
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Robert Treat)
belched out:
> On Tuesday 12 September 2006 14:49, Bruce Momjian wrote:
>> Andrew Dunstan wrote:
>> > Bruce Momjian wrote:
>> > > I again will not be able to complete the release notes today as
>> > > promised. My next tar
1 - 100 of 128 matches
Mail list logo
