>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.
* Allow regression tests to be run on Win32
Tom Lane wrote:
>>> I think there's a reasonable argument that by installing
>>> a .a file that isn't a shared library, we are violating
>>> the platform's conventions.
>
> Hm. This seems possible with some moderate hacking on Makefile.shlib
> (certainly it'd be no more invasive than the existing
The list of functions for:
* Add SQL2003-standard statistical aggregates (Sergey Koposov)
regr_intercept, regr_slope, regr_r2, corr, covar_samp, covar_pop,
regr_avgx, regr_avgy, regr_sxy, regr_sxx, regr_syy, regr_count
Also, I guess that the point
* Aggregate functions now support multiple in
Tom Lane <[EMAIL PROTECTED]> writes:
> I changed the locking thing I was worried about. Unless Greg wants to
> do some real-world performance measurements to confirm or refute that
> change, I think this can be closed.
I could do some if you're curious but my feeling is that the conservative
ch
Is there any utility in postgresql which can do the following?
The utility must update the table whenever there is any change in the
text file.
COPY command helps to do that, though this is not straight forward.
Can it be automated?
Thanks
Dhanaraj
---(end of broadcast
Hi, Jeremy,
Jeremy Drake wrote:
>>> Another possibility would be to test these patches in some kind of virtual
>>> machine that gets blown away every X days, so that even if someone did get
>>> something malicious in there it wouldn't last long.
>
> Or just have a snapshot which is reverted afte
Hi, Jim,
Jim Nasby wrote:
> I'd love to have the ability to control toasting thresholds manually.
> This could result in a lot of speed improvements in cases where a
> varlena field isn't frequently accessed and will be fairly large, yet
> not large enough to normally trigger toasting. An address
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> But the interesting thing is that there were 4.6 million elements in the
> s->childXids list. Which is why it took so damn long. I can't quite figure
> out how I induced this state. It is an OLAP server with about 10-20
> connection that run "lo
Tom Lane <[EMAIL PROTECTED]> writes:
> Anyway, given that there's this one nonobvious gotcha, there might be
> others. My recommendation is that we take this off the open-items list
> for 8.2 and revisit it in the 8.3 cycle when there's more time.
I wonder if Theo's recent reported problem with
On Sep 14, 2006, at 7:03 AM, Gregory Stark wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
But the interesting thing is that there were 4.6 million elements
in the
s->childXids list. Which is why it took so damn long. I can't
quite figure
out how I induced this state. It is an OL
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, and then return to the release n
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> We don't use savepoint's too much. Maybe one or two across out 1k or so
> pl/pgsql procs.
Well if they're in a loop...
> We use dbi-link which is plperl. Perhaps that is somehow creating
> subtransactions?
Ok, I more or less see what's going on.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Anyway, given that there's this one nonobvious gotcha, there might be
>> others. My recommendation is that we take this off the open-items list
>> for 8.2 and revisit it in the 8.3 cycle when there's more time.
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> Ok, I more or less see what's going on. plperl creates a subtransaction
> whenever you execute an SPI query from inside a perl function. That's so that
> errors in the query can throw perl exceptions and be caught in the perl code.
It might also be wor
On Sep 14, 2006, at 8:19 AM, Gregory Stark wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
We don't use savepoint's too much. Maybe one or two across out 1k
or so
pl/pgsql procs.
Well if they're in a loop...
We use dbi-link which is plperl. Perhaps that is somehow creating
subtra
I wrote:
> Yeah, I was just looking at that. Removing useless entries from the
> child-xid list would presumably help him. Considering we're not even
> formally in beta yet, I'm probably being too conservative to recommend
> we not touch it.
Actually ... wait a minute. We do not assign an XID t
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> In production today (8.1.4), I ran into a backend process that
> wouldn't cancel right away -- minutes went by.
> It was in
> [0] TransactionIdIsCurrentTransactionId
> [1] HeapTupleSatisfiesSnapshot
> ...
> But the interesting thing is that there
I wrote:
> I see a bug though, which is that RecordSubTransactionAbort() calls
> GetCurrentTransactionId() before having verified that it needs to do
> anything. This means that we'll generate and then discard an XID
> uselessly in a failed subxact that didn't touch disk.
Well, it would be a bug
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> I personally would prefer 3)a)
> 3) Major hacking in Makefile.shlib to achieve the following:
>- libXX.so.n is built from libXX.a in the traditional way.
> Then libXX.a is deleted, and recreated as archive
> containing libXX.so.n.
>- L
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 target date is Monday, August 18. Sorry.
> >
> > Will that be in a few years, or are you travelin
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 target date is Monday, August 18. Sorry.
> > >
> > > Will that be i
Tom Lane wrote:
> I wrote:
> > I see a bug though, which is that RecordSubTransactionAbort() calls
> > GetCurrentTransactionId() before having verified that it needs to do
> > anything. This means that we'll generate and then discard an XID
> > uselessly in a failed subxact that didn't touch disk.
Tom Lane wrote:
>> 3) Major hacking in Makefile.shlib to achieve the following:
>>- libXX.so.n is built from libXX.a in the traditional way.
>> Then libXX.a is deleted, and recreated as archive
>> containing libXX.so.n.
>>- Linking takes place withOUT -brtl, but with -blibpath:...
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 target date is Monday, August 18.
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 work fine. Note that the currency
symbol is also dropped on output as well but it is accepted on input.
darcy=# select
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think Theo's problem is probably somewhere else, too --- apparently
>> it's not so much that TransactionIdIsCurrentTransactionId takes a long
>> time as that something is calling it lots of times with no check for
>> interrupt.
> Co
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm. The objection I see to this is that it will not support
>> concurrent installation of multiple libpq versions. What about
>>
>> 4) Build and install only libXX.so.n, don't install libXX.a at all
> Won't work - the linker looks
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 work fine. Note that the currency
symbol is also dropped on output as well but it is accepted
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
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
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
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
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
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
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|
-
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
> 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
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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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
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
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-
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
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
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
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:
> 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
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
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:
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:
> 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:
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
* 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
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
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
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
* 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
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
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:
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
* 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
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
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
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,
* 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:
> "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
>
> >
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
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
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
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
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
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
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
"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
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,
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
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
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
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.
>
> >
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|
--+
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
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,
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,
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
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:
>> 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
>
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
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.
And thank goodness for that!
Tom
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
1 - 100 of 128 matches
Mail list logo