* Improve multicolumn GiST index (oleg,teodor)
* GiST indexes now are clusterable (teodor)
* tsearch2 improvements (oleg, teodor):
- multibyte encoding support (including UTF8)
- query rewriting support
- improve ranking functions
- thesaurus dictionary
- Ispell dictionary now recognize
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 there.
--
Guillaume
-
Ü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 list for
> 8.2, and then return to
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.
--
Bruce Momjian [EMAIL PROTECTED]
Enterpr
Tom Lane wrote:
> I'm having a hard time getting excited about improving this query when
> it's so badly coded in the first place. What's an ORDER BY doing in
> an EXISTS subquery? The LIMIT is unnecessary too. And the inner WHERE
> says nothing so much as "I don't know how to design a database
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 were 4.6 million elements in
the s->childXids list. Whi
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Please provide a stack trace --- AFAIK there shouldn't be any reason why
a pass-by-ref 3-byte type wouldn't work.
(gdb) bt
#0 0xb7e01d45 in memcpy () from /lib/libc.so.6
#1 0x08077ece in heap_fill_tuple (tupleDesc=0x83
Mark Dilger <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Please provide a stack trace --- AFAIK there shouldn't be any reason why
>> a pass-by-ref 3-byte type wouldn't work.
> (gdb) bt
> #0 0xb7e01d45 in memcpy () from /lib/libc.so.6
> #1 0x08077ece in heap_fill_tuple (tupleDesc=0x83c2ef7,
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)
Store only active XIDs in subtransaction cache
Per my note just now, this probably should wait fo
I wrote:
> ... it seems like in the
> case where RecordSubTransactionCommit detects that the subxact has not
> stored its XID anywhere, we could immediately remove the XID from
> the PGPROC array, just as if it had aborted. This would avoid chewing
> subxid slots for cases such as exception blocks
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
int1 works perfectly, as far as I can tell. int3 works great in memory,
but can't be stored to a table. The problem seems to be that
store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
me to pass int3 by reference.
Joshua Reich <[EMAIL PROTECTED]> writes:
> I lurk... I don't know if I'm a 'statistics jock', but I may be
> valuable if only I had a better understanding of how the optimizer
> works. I have been following this thread with interest, but could really
> do with a good pointer to background infor
Jeremy Drake wrote:
On Wed, 13 Sep 2006, Tom Dunstan wrote:
I was under the impression that most VM products are x86 centric, which
wouldn't lead to huge amounts of diversity in the buildfarm results. At least,
not as far as architecture goes.
I have played with QEmu (www.qemu.org) which is o
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I see a number of non-ASCII characters in the names of patch submitters
> > in the CVS logs. Does anyone know a good way to have all these get the
> > same encoding in the CVS commit logs? I am thinking that is impossible
> > because we can't attac
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jim Nasby) wrote:
> I'd love to have the ability to control toasting thresholds
> manually. ... Being able to force a field to be
> toasted before it normally would could drastically improve tuple
> density without requiring the developer t
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> ... I can't think of a use case where a user would not want to
> append a "is_visible" clause to the query above. That or start
> tracking which pg_temp_ schema belongs to whom.
Well, I'm still having a problem with this, because it seems like a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think the best you could do is post the non-ASCII names here, and have
> affected people post back their names in HTML escaping or something that
> suits the SGML docs.
That's probably the best way to close the loop. I know that when I'm
committing s
Bruce Momjian wrote:
> I see a number of non-ASCII characters in the names of patch submitters
> in the CVS logs. Does anyone know a good way to have all these get the
> same encoding in the CVS commit logs? I am thinking that is impossible
> because we can't attach the email encoding to the comm
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
>> The patch did not work for me :-(
> Is libpq.so in a non-standard directory? If yes, one either
> has to export LIBPATH in the environment or link with
> -L/location/of/libpq for the executable to find it
> (similar to RPATH in Linux).
libpq will defi
Ron Mayer wrote:
Gregory Stark wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
...vastly overestimate the number of pages .. because postgresql's guess
at the correlation being practically 0 despite the fact that the distinct
values for any given column are closely packed on a few pages.
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
>> But forcing a reload of pltcl.so is nothing but a kluge --- it leaks
>> memory like there's no tomorrow, and it's only an accident that it fails
>> to crash. I don't want to design a further kluge on top of it.
> Are you saying that pltcl.so leaks
On Wed, 13 Sep 2006, Tom Dunstan 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 a
"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
> I agree with that.
OK, Bruce h
But forcing a reload of pltcl.so is nothing but a kluge --- it leaks
memory like there's no tomorrow, and it's only an accident that it fails
to crash. I don't want to design a further kluge on top of it.
Are you saying that pltcl.so leaks memory in general, or that forcing a
reload of the plt
Ron Mayer <[EMAIL PROTECTED]> writes:
> I'm wildly guessing that, the # of pages itself seems to be
> a bigger factor than the sequential/random nature.
No, they're both important: fetching N pages in sequence is way cheaper
than fetching the same number of pages scattered all over. This is
partl
Gregory Stark wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
>> ...vastly overestimate the number of pages .. because postgresql's guess
>> at the correlation being practically 0 despite the fact that the distinct
>> values for any given column are closely packed on a few pages.
>
> I think we n
Jim Nasby wrote:
That's something I'd be willing to do. And for many people that aren't
committers but are still trusted in the community, we could probably
bypass the checking.
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regula
Jim Nasby <[EMAIL PROTECTED]> writes:
> Isn't having more lock partitions than buffer partitions pointless?
AFAIK they're pretty orthogonal. It's true though that a typical
transaction doesn't hold all that many locks, which is why I don't
see a need for a large number of lock partitions.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I guess the question is whether it is possible using cvs2cl to show only
> HEAD, and then show if the same commit message also appears in the most
> recent back branch.
It's so rare that we make a back-branch patch without a corresponding
HEAD patch that
I see a number of non-ASCII characters in the names of patch submitters
in the CVS logs. Does anyone know a good way to have all these get the
same encoding in the CVS commit logs? I am thinking that is impossible
because we can't attach the email encoding to the commit message.
--
Bruce Momj
Mark Dilger <[EMAIL PROTECTED]> writes:
> int1 works perfectly, as far as I can tell. int3 works great in memory,
> but can't be stored to a table. The problem seems to be that
> store_att_byval allows data of size 1 byte but not size 3 bytes, forcing
> me to pass int3 by reference. But when
Mark Dilger wrote:
Tom Lane wrote:
Mark Dilger <[EMAIL PROTECTED]> writes:
... The argument made upthread that a quadratic number of conversion
operators is necessitated doesn't seem right to me, given that each
type could upcast to the canonical built in type. (int1 => smallint,
int3 => int
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
> I want to be able to tell a backend to reinitialize some of the cached
> data it is holding in static variables. Generally I want to do this
> when the something "cached" in memory has gotten out-of-sync with what
> is in the database. The two examp
On Sep 13, 2006, at 2:46 PM, Strong, David wrote:
We have some results for you. We left the buffer partition locks at
128
as this did not seem to be a concern and we're still using 25 backend
processes. We ran tests for 4, 8 and 16 lock partitions.
Isn't having more lock partitions than buffe
"Strong, David" <[EMAIL PROTECTED]> writes:
> We have some results for you. We left the buffer partition locks at 128
> as this did not seem to be a concern and we're still using 25 backend
> processes. We ran tests for 4, 8 and 16 lock partitions.
> For 4 lock partitions, it took 620 seconds to
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> > I pull activity only from HEAD, so I do not see that tag. In fact, I
> >> > use our src/tools/pgcvslog rather than cvslog.
> >>
> >> Not sure why we are maintaining our own script
On Sep 13, 2006, at 6:56 PM, Tom Dunstan wrote:
Regarding the idea of a list of approved patch authorisers, don't
we have
such a group now? i.e. "committers".
Right, and if committers or others are willing to put in the time
required to verify that patches aren't nasty before going onto the
On Sep 11, 2006, at 1:57 PM, Gregory Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
I think its's more important to pick bitpatterns that reduce the
number of
cases heap_deform_tuple has to think about while decoding the
length of a
field --- every "if" in that inner loop is expensive.
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
> 1. Is the invalidation of stored plans going to be part of 8.2? If
> not, any idea when it would be available? I'd be willing to work on
> this, if it would help.
No, it did not get done; feel free to work on it for 8.3.
[steve's reply]:
Could
On Sep 13, 2006, at 14:44 , Gregory Stark wrote:
I think we need a serious statistics jock to pipe up with some
standard
metrics that do what we need. Otherwise we'll never have a solid
footing for
the predictions we make and will never know how much we can trust
them.
That said I'm no
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> > I pull activity only from HEAD, so I do not see that tag. In fact, I
>> > use our src/tools/pgcvslog rather than cvslog.
>>
>> Not sure why we are maintaining our own script when there are much
>> better thing
Tom,
We have some results for you. We left the buffer partition locks at 128
as this did not seem to be a concern and we're still using 25 backend
processes. We ran tests for 4, 8 and 16 lock partitions.
For 4 lock partitions, it took 620 seconds to acquire locks and 32
seconds to release locks.
Ron Mayer <[EMAIL PROTECTED]> writes:
> It's common here for queries to vastly overestimate the
> number of pages that would need to be read because
> postgresql's guess at the correlation being practically 0
> despite the fact that the distinct values for any given
> column are closely packed on
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
> 1. Is the invalidation of stored plans going to be part of 8.2? If not,
> any idea when it would be available? I'd be willing to work on this, if
> it would help.
No, it did not get done; feel free to work on it for 8.3.
> 2. Is there any plan for
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I pull activity only from HEAD, so I do not see that tag. In fact, I
> > use our src/tools/pgcvslog rather than cvslog.
>
> Not sure why we are maintaining our own script when there are much
> better things out there:
> http://freshm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I pull activity only from HEAD, so I do not see that tag. In fact, I
> use our src/tools/pgcvslog rather than cvslog.
Not sure why we are maintaining our own script when there are much
better things out there:
http://freshmeat.net/projects/cvs2cl.pl/
Tom,
Thanks for the update on the roadmap. I have a couple of questions:
1. Is the invalidation of stored plans going to be part of 8.2? If not,
any idea when it would be available? I'd be willing to work on this, if
it would help.
2. Is there any plan for the other part of my proposal, i.e.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > FYI, in going through the release notes, I would like to remind
> > committers that it is important to mention if the commit was backpatched
> > to any earlier release. Not only is this valuable for making the
> > release notes, but i
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After wri
Stephen Marshall <[EMAIL PROTECTED]> writes:
> The following is a proposal for work I'd like to do to force
> long-running backend processes to reprepare their prepared statements.
> It would be used in cases where the user knows they have made a database
> change that will invalidate an existi
[EMAIL PROTECTED] ("Rocco Altier") writes:
>> Tom Lane wrote:
>> > Is it
>> > possible that the rules have changed across AIX versions,
>> > and that the code in there now is needful for older versions?
>>
>> I don't think that this behaviour has changed. I remember it from
>> AIX 4.3.2.
>>
> AI
Bruce Momjian <[EMAIL PROTECTED]> writes:
> FYI, in going through the release notes, I would like to remind
> committers that it is important to mention if the commit was backpatched
> to any earlier release. Not only is this valuable for making the
> release notes, but it also helps people lookin
Simon,
In the 16/16 (16 buffer partitions/16 lock partitions) test, the
WALInsertLock lock had 14643080 acquisition attempts and 12057678
successful acquisitions on the lock. That's 2585402 retries on the lock.
That is to say that PGSemaphoreLock was invoked 2585402 times.
In the 128/128 test, th
The following is a proposal for work I'd like to do to force
long-running backend processes to reprepare their prepared statements.
It would be used in cases where the user knows they have made a database
change that will invalidate an existing prepared statement.
I look forward to comments
On Wed, 2006-09-13 at 14:24 +0400, Teodor Sigaev wrote:
> Patch adds GIN documentation and slightly improves GiST docs.
>
> Somebody of native English speakers, pls, check the text... Thank you.
I have some minor changes that reworded some parts that were confusing
to me.
I don't fully understan
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > FYI, in going through the release notes, I would like to remind
> > committers that it is important to mention if the commit was
> > backpatched to any earlier release.
>
> Backpatches usually happen after the commit to the head branch has been
>
Bruce Momjian wrote:
> FYI, in going through the release notes, I would like to remind
> committers that it is important to mention if the commit was
> backpatched to any earlier release.
Backpatches usually happen after the commit to the head branch has been
made, so the information is not avail
Simon Riggs wrote:
> On Mon, 2006-09-11 at 06:20 -0700, Say42 wrote:
>> 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.
"Not
FYI, in going through the release notes, I would like to remind
committers that it is important to mention if the commit was backpatched
to any earlier release. Not only is this valuable for making the
release notes, but it also helps people looking at the commit message.
--
Bruce Momjian [E
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I have seen some patches come across with this. Is this done, or do I
> still need to work on it?
Teodor added an uninstall for hstore, and I think Michael has fixed all
the problems in the existing scripts, but we still lack uninstall
scripts for t
On 9/13/06, Tom Lane <[EMAIL PROTECTED]> wrote:
statement: querystring Simple Query
parse : querystring Parse
bind /: querystring Bind
execute /: querystringExecute
I agree with that.
Hmmm, AFAICS, you changed "/" to " to
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> IMHO, it's more logical to remove it as the text after statement: is
> not a statement in the extended query protocol case.
Well, I was never particularly enamored of the idea that we should put
statement: into everything generated by log_statement.
> The patch did not work for me :-(
>
> My buildfarm members failed in local testing to execute the
> install-check, because initdb failed to find libpq.so.
>
> Make check did succeed, so I think there is a possibility of
> getting it
> working, but it won't be as simple as adding -brtl to the t
The patch did not work for me :-(
My buildfarm members failed in local testing to execute the
install-check, because initdb failed to find libpq.so.
Make check did succeed, so I think there is a possibility of getting it
working, but it won't be as simple as adding -brtl to the template.
I was a
On Wed, Sep 13, 2006 at 10:47:09AM -0400, Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Apparently we've made the planner a bit too optimistic about the savings
> >> that can be expected from repeated indexscans occurring on the inside of
> >> a join.
>
> Tom Lane wrote:
> > Is it
> > possible that the rules have changed across AIX versions,
> > and that the code in there now is needful for older versions?
>
> I don't think that this behaviour has changed. I remember it from
> AIX 4.3.2.
>
AIX 4.3 is the first version to support the -brtl. The
On 9/13/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> I attached a patch to improve the consistency. It adds statement: for
> every case.
Isn't that just bloating the log? And weren't you the one complaining
about log volumes to begin with?
As I told y
Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Apparently we've made the planner a bit too optimistic about the savings
that can be expected from repeated indexscans occurring on the inside of
a join.
effective_cache_size was set to 10GB(my fault for copying
"Say42" <[EMAIL PROTECTED]> writes:
> ... Let's take my pervious example (I repost query and some lines
> from 'explain' here for convenience):
> select count(*) from conn.conn20060803 c where
> exists (select code from belg_mobile tc
> where c.bnum >= tc.code and c.bnum like tc.code |
Andrew Dunstan wrote:
Tom's idea of making a temp copy of the repo and patching that would work,
but if you're going to do that why do a vpath build anyway?
In this case, the answer is to make sure that your patch works when
*someone else* does a vpath build.
Regarding the idea of a list of
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Apparently we've made the planner a bit too optimistic about the savings
>> that can be expected from repeated indexscans occurring on the inside of
>> a join.
> effective_cache_size was set to 10GB(my fault for copying over the
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> I attached a patch to improve the consistency. It adds statement: for
> every case.
Isn't that just bloating the log? And weren't you the one complaining
about log volumes to begin with?
The reason it is why it is is that Bruce wanted the wording to
Alvaro Herrera wrote:
>
> Huh, but the patch can be applied with -R to revert it after the
> buildfarm run ... the one problem I can see is if the patch fails for
> some reason; for which I'd suggest running a patch --dry-run as a first
> step, checking that it applies cleanly, and only continue in
Tom Dunstan wrote:
> Alvaro Herrera wrote:
> >>I submitted a patch to Andrew, but it needed a couple of tweaks
> >>(disabling patching on vpath builds, for example) and I don't think I
> >>ever got around to resubmitting it, but if there's more general interest
> >>I'll do so.
> >
> >Huh, why wo
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable patching on vpath builds?
Tom,
I'm currently resyncing my parser with the changes you made to
prepared statement logging. Everything is OK apart from an
inconsistency between log_duration and log_min_duration_statement.
* With log_duration, we have:
protocol : LOG: statement: execute my_query: SELECT * FROM shop WHERE $
Tom Dunstan wrote:
> The idea was that patch authors could either run it manually or stick it
> in a cron so they could get emailed when the patch no longer cleanly
> applied, or when the patched source failed in make, make check etc.
> Obviously my motivation was to keep the enum patch up to d
Peter Eisentraut wrote:
> But you haven't offered any analysis about the cause of this problem, so any
> speculation about normalization, usual cases, caching effects and so on are
> unfounded and premature.
Ok. My previous message was a bit pompous and unfounded. Sorry.
Below I'll try to explain
Patch adds GIN documentation and slightly improves GiST docs.
Somebody of native English speakers, pls, check the text... Thank you.
gindocs.gz
Description: application/gzip
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Hi, Tom,
Tom Lane wrote:
> AFAIR what was discussed was separating
> - schema stuff needed before loading data
> - table data
> - schema stuff needed after loading data
> where the last category boils down to "indexes and then foreign keys".
> All the "other stuff" such as funct
On Tue, 2006-09-12 at 12:40 -0400, Tom Lane wrote:
> "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
On Tue, 2006-09-12 at 16:23 -0400, Tom Lane wrote:
> 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,
Say42 wrote:
> Perhaps I am wrong but I assume normalization is a usual case, small
> master (parent) tables are not very rare also.
> Yes, my example is unusual but it is _real_ and demonstrate PG
> optimizer inaccuracy. Why don't we make PG optimizer more close to
> reality if we can? Is it so ne
Jim C. Nasby wrote:
> There's been talk in the past of having some kind of system that
> automatically attempts to build things that are in the patch queue, both
> as an initial sanity-check and as a means to detect when something
> bit-rots... perhaps it's becoming worthwhile to set that up.
Aft
Tom Lane wrote:
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
85 matches
Mail list logo
