Tom Lane <[EMAIL PROTECTED]> writes:
> The project policy has always been that we don't change on-disk formats
> in minor releases. I'm not entirely clear why you are so keen on
> carving out an exception for WAL data.
I had always thought of the policy as "initdb is not required" not "no on-dis
On Sat, Sep 02, 2006 at 09:26:36PM -0700, Joshua D. Drake wrote:
>
> >>>I just spent 1/2 hour fixing the multi-value UPDATE
> >>>patch for the code drift caused by UPDATE/RETURNING. The patch is a
> >>>simple grammar macro. Any coder could have taken that, reviewed it, and
> >>>applied it, but n
Tom Lane wrote:
> Optimizing on the basis of only one example is seldom a good idea...
> and I think you are falling into that trap by supposing that there
> is a "usual case".
Perhaps I am wrong but I assume normalization is a usual case, small
master (parent) tables are not very rare also.
Yes,
On Fri, Sep 01, 2006 at 03:28:36PM -0400, Stephen Frost wrote:
> Overall, I really think 8.2 is going to be an excellent release. I wish
> autovacuum could have been enabled by default and I'd just like to ask,
> now and I'll try to remember again once 8.2 is out, please let's turn it
> on by defa
Say42 wrote:
> select count(*) from conn.conn20060803 c
> where
> exists (select code from belg_mobile tc
...
Correction: replace 'trunk_codes' with 'belg_mobile'.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
"Say42" <[EMAIL PROTECTED]> writes:
> Usual case in data request is a joining detail and some master tables
> into a single relation.
Optimizing on the basis of only one example is seldom a good idea...
and I think you are falling into that trap by supposing that there
is a "usual case".
Peter Eisentraut wrote:
> If you know of a more effective way to do that beyond the effective_cache_size
> parameter that we have now, let us know.
I don't know the better way and it is not my goal at all. I think about
more accurate cost estimation of nested loops join and subqueries.
Usual case
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at 02:31
> I have just realized that the recent patches in pgbench have altered its
> behavior in a way that destroys reproducibility of results --- I'm
> seeing reported TPS numbers about twice what they were before that.
> I'd love to say we did something in the past month that made the backend
> 2X faste
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Could we see the actual EXPLAIN ANALYZE results for the slow plan?
> http://www.kaltenbrunner.cc/files/dbt3_explain_analyze.txt
Well, indeed it seems that the hash join is just an innocent bystander:
the bulk of the runtime (al
If everything goes okay, I should be able to submit a beta patch for
reviewing during next two weeks (and get shot at :))
/me starts loading...
Regards,
Gevik
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, plea
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, you're much mistaken about this
Naz Gassiep wrote:
>
> >None, but feel free to start coding for 8.3.My coding skills are still
> >nascent, but I shall do my best.
> My coding skills are still pretty nascent, but I shall do my best.
> >
> >That seems like a rather spectacular overstatement of the likely
> >benefits, not to menti
None, but feel free to start coding for 8.3.My coding skills are still nascent,
but I shall do my best.
My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was di
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well it's never been a factor before so I'm not sure there is a
> policy. Is there now a policy that WAL files like database formats are
> as far as possible not going to be changed in minor versions?
> This means if there's a bug fix that affects WAL re
Tom Lane <[EMAIL PROTECTED]> writes:
> This would be the exception, not the rule, and should not be documented
> as if it were the rule. It's not really different from telling people
> to expect a forced initdb at a minor release: you are simply
> misrepresenting the project's policy.
Well it's
Folks,
During past days I have been coding the UUID datatype which has been fun
and great learning curve for me. Here is the current progress:
- basic i/o functions are done.
- various records for pg_class,pg_operator,pg_amop etc, are added
- the additions pass the regression check :)
- btree and
Bruce Momjian wrote:
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
Sent: 12 September 2006 19:57
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Release notes
On Tue, Sep 12, 2006 at 02:31:22PM -0
Gregory Stark <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>>> My memory is lousy at the best of times, but when have we had a minor
>>> release that would have broken this due to changed format?
>> Not often, which is why I mention the possibility of having
>> interopera
Simon Riggs <[EMAIL PROTECTED]> writes:
>> My memory is lousy at the best of times, but when have we had a minor
>> release that would have broken this due to changed format? OTOH, the
>> Primary and Backup servers need the same config settings (e.g.
>> --enable-integer-datetimes), architecture
Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
> > Sent: 12 September 2006 19:57
> > To: Bruce Momjian
> > Cc: PostgreSQL-development
> > Subject: Re: [HACKERS] Release notes
> >
> > On Tue, Sep 12, 2006 a
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr
> Sent: 12 September 2006 19:57
> To: Bruce Momjian
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Release notes
>
> On Tue, Sep 12, 2006 at 02:31:22PM -0400, Bruce Momjian wrote
On Tue, Sep 12, 2006 at 02:31:22PM -0400, 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.
The next Monday, August 18, is in 2008. Surely that'll be
enough time ;-)
--
Michael Fuhr
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 traveling backwards in time? ;-)
Sorry, September 18. I will pr
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 traveling backwards in time? ;-)
cheers
andrew
---(end of broadcast)--
I again will not be able to complete the release notes today as
promised. My next target date is Monday, August 18. Sorry.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
On Tue, 2006-09-12 at 13:25 -0400, Andrew Dunstan wrote:
> Simon Riggs wrote:
> >
> > In general, log shipping between servers running different release
> > levels will not be possible. However, it may be possible for servers
> > running different minor release levels e.g. 8.2.1 and 8.2.2 to
> > in
Simon Riggs wrote:
In general, log shipping between servers running different release
levels will not be possible. However, it may be possible for servers
running different minor release levels e.g. 8.2.1 and 8.2.2 to
inter-operate successfully. No formal support for that is offered and
there ma
On Wed, 2006-09-06 at 12:01 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > 1. Notes on restartable recovery
Previously submitted
> > 2. Notes on standby functionality
> > 3. discussion on rolling your own record-level polling using
> > pg_xlogfile_name_offset()
Given below, but not in SGML
Tom,
Thanks for the feedback. We'll run a few tests with differing buffer and
lock partition sizes in the range you're interested in and we'll let you
know what we see.
Our workload is not fixed, however. Our benchmark does not follow the
strict TPC-C guideline of using think times etc. We throw
"Strong, David" <[EMAIL PROTECTED]> writes:
> When using 16 buffer and 16 lock partitions, we see that BufMapping
> takes 809 seconds to acquire locks and 174 seconds to release locks. The
> LockMgr takes 362 seconds to acquire locks and 26 seconds to release
> locks.
> When using 128 buffer and 1
Hi Heikki,
Gavin and I are trying to merge our changes together this week. We will post
a new patch by the end of this week. This patch will include some style
fixes, bug fixes, and the stream bitmap implementation.
I will look into the problems you have mentioned in this email. Yes, vacuum
curre
Tom Lane wrote:
>> The natural way in AIX would be:
>> - Create libpq.so
>> - Create libpq.a by 'rm -f libpq.a; ar -rc libpq.a libpq.so'
>> - Install only libpq.a
>
> Hm. This seems possible with some moderate hacking on Makefile.shlib
> (certainly it'd be no more invasive than the existing Windo
We can pass on what we've seen when running tests here with different
BufMapping and LockMgr partition sizes.
We use a TPC-C inspired benchmark. Currently it is configured to run 25
backend processes. The test runs for 16 minutes as this is the minimum
amount of time we can run and obtain useful i
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was discussed.
AFAIR what was discussed was separating
Yes, that is what was discussed.
- schema stuff needed before loading data
- table data
- schema
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> It has bothered me for some time that we have currentItemData and
> currentMarkData fields in IndexScanDescData, while it's really indexam's
> private data. They should be in the indexam opaque structure.
Can't get very excited about it, but if yo
Naz Gassiep <[EMAIL PROTECTED]> writes:
> At risk of being chastised for reviving old issues, I was wondering,
> what are the chances were of getting the dump / restore selectivity into
> 8.2 ?
None, but feel free to start coding for 8.3.
> I am referring to the idea that, instead of the curren
Zero, because feature freeze is over.
Aah yes, fair enough
If you find this feature interesting, you are free to drive the development
yourself, independent of it appearing on any list. To avoid tears later on,
look for a consensus about the merit of the feature first, though
This has be
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's possible there's some sort of "block-wise correlated" measure
> which would be even better for our needs.
Actually, it seems obvious to me that the correlation measure ought to
ignore within-block ordering, but right now it does not. OTOH it's not
Am Dienstag, 12. September 2006 12:48 schrieb Say42:
> That is why caching should be taking into account
> during joining cost calculation.
If you know of a more effective way to do that beyond the effective_cache_size
parameter that we have now, let us know.
--
Peter Eisentraut
http://develope
Am Dienstag, 12. September 2006 15:22 schrieb Naz Gassiep:
> At risk of being chastised for reviving old issues, I was wondering,
> what are the chances were of getting the dump / restore selectivity into
> 8.2 ?
Zero, because feature freeze is over.
> Did this item make it onto the to-do list? I
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What's the status of the bitmap index patch? Have you worked on it since
> the last posted patch
> (http://archives.postgresql.org/pgsql-patches/2006-08/msg3.php)?
Gavin and Jie have made major changes since that version (or at least
they'd be
It has bothered me for some time that we have currentItemData and
currentMarkData fields in IndexScanDescData, while it's really indexam's
private data. They should be in the indexam opaque structure.
At the moment, they're used in gist and hash access methods, and they're
not used in b-tree a
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> 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.
> The natural way in AIX would be:
> - Create libpq.so
> - Create libpq.a by 'rm -f libpq.
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-09-11 at 11:29 -0400, Tom Lane wrote:
>> Great, thanks. The thing to twiddle is LOG2_NUM_LOCK_PARTITIONS in
>> src/include/storage/lwlock.h. You need a full backend recompile
>> after changing it, but you shouldn't need to initdb, if that hel
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ? I am referring to the idea that, instead of the current 2 parts, a
dump could be broken up into 3 parts, namely tables, data and everything
else, s
Tom Lane wrote:
>> In our case, we have libpq.a and libpq.so in the same directory,
>> so unless you link with -brtl you will get a static link
>> (because libpq.a is a static library).
>
> I wonder whether we ought to suppress building (or at least
installing)
> our .a libraries at all on AIX. A
Simon Riggs wrote:
> This type of work is 90% analysis, 10% coding. You'll need to do a lot
> of investigation, lots of discussion and listening.
I absolutely agree with you and I am not about to rush into coding
right now. First of all I'm going to dig a lot in the PG sources,
readme's and so on.
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
btw - the "hashjoin is bad" was more or less based on the observation
that nearly all of the cpu is burned in hash-related functions in the
profile (when profiling over a longer period of time those accumulate
even more % of the ti
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 type instead.
>
> What semantics?
Simon Riggs <[EMAIL PROTECTED]> writes:
>> That's what I want to do:
>> 1. Replace not very useful indexCorrelation with indexClustering.
>
> An opinion such as "not very useful" isn't considered sufficient
> explanation or justification for a change around here.
There's been some previous discus
Hi,
What's the status of the bitmap index patch? Have you worked on it since
the last posted patch
(http://archives.postgresql.org/pgsql-patches/2006-08/msg3.php)?
I've started to review it, to get it into CVS early in the 8.3 cycle. I
just want to make sure that I'm working on the lates
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Christopher Browne wrote:
>
>> It seems to me that there is some value in putting together a script
>> that tries to identify some of the interesting bits of the toolchain.
>
> Yeah; but why not just a bunch of commands, some of which are expected
> to
On Mon, 2006-09-11 at 14:25 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Is this an 8.2 thing?
>
> You are joking, no?
Confirming, using an open question, and a smile.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
On Mon, 2006-09-11 at 06:20 -0700, Say42 wrote:
> I intend to play with some optimizer aspects. Just for fun.
Cool. If you think its fun (it is), you're half way there.
> I'm a
> novice in the DBMS development so I can not promise any available
> results but if it can be useful even as yet anoth
On Mon, 2006-09-11 at 11:29 -0400, 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 p
Kevin Brown wrote:
>>> Let me expand a little on some of the peculiarities of
>>> shared libraries on AIX:
>>
>>> - A normal AIX shared library is called libXX.a
>>> It is an 'ar' archive that contains the shared object(s).
>>
>> Ah, so the problem really boils down to funny naming conventions.
57 matches
Mail list logo
