[already sent a variant of that yesterday but it doesn't look like it
made it to the list]
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
Understood, Thank you :)
On Sat, 2006-09-16 at 21:23 -0400, Tom Lane wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
This assumes a fact not in evidence, which is that we're going
Hi Heikki and all,
I just sent the latest bitmap index patch to the list. I am not sure if
there is any size limit for this mailing list. If you have received my
previous email, please let me know.
Thanks,
Jie
On 9/12/06 2:43 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Hi,
What's the
On Sat, Sep 16, 2006 at 04:19:48PM -0400, Tom Lane wrote:
I've applied this along with some extra work to get it to show GMT
offsets and DST status, which should be useful for helping people
to choose which setting they want. This effectively obsoletes
Table B-5 as well as B-4 in the SGML
On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Gregory Stark wrote:
A TODO list people can freely add stuff to is precisely what would make it
useful. It would have things we don't already know.
I am just going to hope that you are
On Sat, Sep 16, 2006 at 08:56:11PM +0100, Gregory Stark wrote:
[Re inet and cidr]
Why are these varlena? Just for ipv6 addresses? Is the network mask length not
stored if it's not present? This gives us a strange corner case in that ipv4
addresses will *always* fit in the smallfoo data type
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Sep 16, 2006 at 08:56:11PM +0100, Gregory Stark wrote:
[Re inet and cidr]
Why are these varlena? Just for ipv6 addresses? Is the network mask length
not
stored if it's not present? This gives us a strange corner case in that ipv4
Stefan Kaltenbrunner wrote:
[already sent a variant of that yesterday but it doesn't look like it
made it to the list]
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
The wiki has been sitting there for two weeks and hasn't had
any problems.
Uh, you mean apart from the fact that it took very little time (days,
IIRC) before we had people writing attempts at user documentation,
somthing that we already have *two* different systems (interactive docs
+ new
Techdocs is a different problem all together. Josh has
already mentioned some problems with it. I can mention more.
[warning: thread hi-jack]
1. It isn't easy to login
Really? You're kidding, right? You click a link that requires login, and
you get a browser login box. How much easier can
Two points I'm not clear about on this thread though:
1. Authorized user: is that someone with an account, or
someone who has been authorized by someone else?
IIRC, the idea was someone with an account. Basically you add a (very
very small) hurdle so you only get the people who actually
On Sun, Sep 17, 2006 at 03:09:29PM +0200, Magnus Hagander wrote:
The wiki has been sitting there for two weeks and hasn't had
any problems.
Uh, you mean apart from the fact that it took very little time (days,
IIRC) before we had people writing attempts at user documentation,
snip
The wiki has been sitting there for two weeks and hasn't had any
problems.
Uh, you mean apart from the fact that it took very little
time (days,
IIRC) before we had people writing attempts at user documentation,
snip
Really? Where was that? Did it get deleted in the meantime?
1. Authorized user: is that someone with an account, or someone who has
been authorized by someone else?
In my mind it is someone who without threw a process of email
confirmation. Just to help stave off the amount of trolling that may happen.
Joshua D. Drake
2. I can see the official
1. It isn't easy to login
Really? You're kidding, right? You click a link that requires login, and
you get a browser login box. How much easier can it be?
What URL are you talking about?
http://www.postgresql.org/docs/techdocs
Where do I click login? Where do I click create account? Where
Magnus Hagander wrote:
Two points I'm not clear about on this thread though:
1. Authorized user: is that someone with an account, or
someone who has been authorized by someone else?
IIRC, the idea was someone with an account. Basically you add a (very
very small) hurdle so you only get the
Joshua D. Drake [EMAIL PROTECTED] writes:
1. Authorized user: is that someone with an account, or someone who has
been authorized by someone else?
In my mind it is someone who without threw a process of email confirmation.
Just to help stave off the amount of trolling that may happen.
I
1. It isn't easy to login
Really? You're kidding, right? You click a link that
requires login,
and you get a browser login box. How much easier can it be?
What URL are you talking about?
http://www.postgresql.org/docs/techdocs
Yes.
Where do I click login? Where do I click
-Original Message-
From: Magnus Hagander [EMAIL PROTECTED]
To: Martijn van Oosterhout kleptog@svana.org
Cc: Gregory Stark [EMAIL PROTECTED]; Josh Berkus josh@agliodbs.com;
[EMAIL PROTECTED] [EMAIL PROTECTED]; Neil Conway [EMAIL PROTECTED];
Dave Page dpage@vale-housing.co.uk;
On 2006-09-17, Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Any view over the full timezone names should also include the
corresponding data from zone.tab in the timezone library source.
Just noticed this mail, so that's not included in my patch.
BTW, now that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
AFAIK, nobody has stepped up to actually take *responsibility* for
maintaining the wiki - both software and content-wise. But I may have
missed something while I speed-read some lists after getting back.
I'm responsible for the software. I'll
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
1. Authorized user: is that someone with an account, or someone who has
been authorized by someone else?
In my mind it is someone who without threw a process of email confirmation.
Just to help stave off the amount of trolling
On Sat, 16 Sep 2006, Josh Berkus wrote:
Hi,
Greg,
I think the lessons of wikipedia is precisely that you *don't* want to add
such barriers. You want to let people add stuff pretty much freely. That
encourages people to get involved and put up information.
The other lesson of Wikipedia is
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
Fortunately, none of the real developers would have to pay any attention
to any such page ... and you can bet they wouldn't.
If someone wants to spend an afternoon putting up a coherent
Dan Thomas [EMAIL PROTECTED] writes:
I've been having trouble running vacuumdb -a and pg_dumpall
concurrently because they run through the databases in a different
order (so dumpall was getting stuck behind vacuum's lock, and my
firewall was rather unhelpfully closing the idle connection).
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Sep 16, 2006 at 09:15:24PM -0400, Tom Lane wrote:
Fortunately, none of the real developers would have to pay any attention
to any such page ... and you can bet they wouldn't.
If someone wants to
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
that is the explain for the 4h+ Q9:
http://www.kaltenbrunner.cc/files/analyze_q9.txt
The big problem there seems to be the drastic misestimation of the
number of rows matching the p_name ~~ '%ghost%' condition. What does
pg_stats have for the
Tom proposed a modest roadmap type experiment a week or so ago. I'd like
to see that pursued. After all, we know of some things that are at least
at first cut stage for 8.3, and a few things high on may people's
agenda. I'd also like to see some work done on using a tracker (for
features as
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
that is the explain for the 4h+ Q9:
http://www.kaltenbrunner.cc/files/analyze_q9.txt
The big problem there seems to be the drastic misestimation of the
number of rows matching the p_name ~~ '%ghost%' condition. What does
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
some additional numbers(first one is with default settings, second is
with enable_nestloop = 'off', third one is with enable_nestloop = 'off'
and enable_hashjoin='off'):
http://www.kaltenbrunner.cc/files/analyze_q7.txt
I'm inclined to think you
Um, whaddya mean dumpall was getting stuck behind vacuum's lock?
A plain vacuum doesn't take any locks that would block pg_dump.
Dammit, just looked and the setup I originally encountered the problem
on and tracked it down to the vacuum process, and it is indeed set up
to perform a full
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
The big problem there seems to be the drastic misestimation of the
number of rows matching the p_name ~~ '%ghost%' condition. What does
pg_stats have for the p_name column?
http://www.kaltenbrunner.cc/files/pg_stat_p_name.txt
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
some additional numbers(first one is with default settings, second is
with enable_nestloop = 'off', third one is with enable_nestloop = 'off'
and enable_hashjoin='off'):
http://www.kaltenbrunner.cc/files/analyze_q7.txt
I'm
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure what we could do about the concurrent-sessions issue, but
we could make some sort of attack on the query complexity issue by
pro-rating the effective_cache_size among all the tables used by a
query.
hmm not sure i
On Fri, 2006-09-15 at 09:38 -0700, Joshua D. Drake wrote:
Hello,
Hi Joshua,
Yeah, this is a cross post and it is slightly off topic but IMHO this is
important.
Tomorrow one of our own, Devrim Gunduz is becoming a man. He is sucking
it up, and committing to the cvs repo of project
On 9/15/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Yeah, this is a cross post and it is slightly off topic but IMHO this is
important.
Tomorrow one of our own, Devrim Gunduz is becoming a man. He is sucking
it up, and committing to the cvs repo of project marriage.
May the patches
I see the following items standing between us and putting out 8.2beta1:
* Set client encoding based on OS environment - Peter E.
I'm not sure whether Peter is intending to complete this item for 8.2
or not, but if it's to be done it ought to be done before we start beta.
* The contrib/userlock
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane) wrote:
I see the following items standing between us and putting out 8.2beta1:
* AIX linking issues
This isn't necessarily a beta-stopper, but it'd be nice to get it done
so we can be sure that any beta testing done on
On 9/15/06, Joshua D. Drake [EMAIL PROTECTED] wrote:
Tomorrow one of our own, Devrim Gunduz is becoming a man. He is sucking
it up, and committing to the cvs repo of project marriage.
Congratulations Devrim!
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
or put a hopefully-cleaner design into
On 2006-09-18, James William Pye [EMAIL PROTECTED] wrote:
FWIW, I'm +1 on the cleaner design you suggested. While I understand the
concerns of adding features/API this late;
Adding features is one thing, breaking existing users of the code is another.
--
Andrew, Supernews
regression=# select * from int8_tbl union all select * from int8_tbl order by
q2;
q1|q2
--+---
4567890123456789 | -4567890123456789
4567890123456789 | -4567890123456789
4567890123456789 | 123
4567890123456789 |
Christopher Browne [EMAIL PROTECTED] writes:
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane)
wrote:
I see the following items standing between us and putting out 8.2beta1:
* AIX linking issues
This has to do with the discussion about shared vs static libs?
If a
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-09-18, James William Pye [EMAIL PROTECTED] wrote:
FWIW, I'm +1 on the cleaner design you suggested. While I understand the
concerns of adding features/API this late;
Adding features is one thing, breaking existing users of the code is
On Sep 15, 2006, at 11:32 PM, Jeremy Drake wrote:
When I was first dealing with postgres, I found it extremely
annoying that
I had to type out double precision rather than just double
since every
sane programming language (as well as Java) uses double. I eventually
figured out that it was
On Sep 16, 2006, at 9:31 PM, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Then we should change autovacuum so that it stays out of the way when
tables are being vacuumed frequently enough via an external means.
What makes you think it doesn't do that already? Of course, it has
On Sep 16, 2006, at 7:31 PM, Gregory Stark wrote:
Would that pose indexing issues? It would also mean that when
joining two
tables you'd have to handle some interesting type conversion
issues (at
times). We had someone accidentally create a largish table with
userid as
numeric and other
On Sep 14, 2006, at 9:16 PM, Golden Liu wrote:
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
On Sun, Sep 17, 2006 at 04:18:36PM -0400, Tom Lane wrote:
* table and index. (Ideally other_pages should include all the other
* tables and indexes used by the query too; but we don't have a good way
* to get that number here.)
A first-order approximation to this would be to add up the
Jim Nasby [EMAIL PROTECTED] writes:
On Sep 14, 2006, at 9:16 PM, Golden Liu wrote:
I try to solve this problem this way:
First, update the table t but DON'T update the index.
Next, find all the tuples updated by this command and insert them into
the unique index.
I suspect that your change
On Mon, Sep 18, 2006 at 12:29:56AM +0300, Enver ALTIN wrote:
On Fri, 2006-09-15 at 09:38 -0700, Joshua D. Drake wrote:
Hello,
Hi Joshua,
Yeah, this is a cross post and it is slightly off topic but IMHO this is
important.
Tomorrow one of our own, Devrim Gunduz is becoming a man.
Jim C. Nasby [EMAIL PROTECTED] writes:
I think it'd be better to attack this problem from the other side;
namely looking at what's actually cached.
You can kiss goodbye to plan stability if you go that route... and
in any case I doubt the assumption that what's in shared buffers is
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
* The contrib/userlock replacement issue
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
On Sun, Sep 17, 2006 at 10:10:52PM -0400, Tom Lane wrote:
I'm inclined to fix this in HEAD but not back-patch it, on the grounds
that there might be apps out there expecting the existing behavior,
and it's not a big enough deal to change behavior in a minor release.
Thoughts?
Isn't the
On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
Tom proposed a modest roadmap type experiment a week or so ago. I'd like
to see that pursued. After all, we know of some things that are at least
at first cut stage for 8.3, and a few things high on may people's
agenda. I'd
On Mon, Sep 18, 2006 at 12:20:10AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think it'd be better to attack this problem from the other side;
namely looking at what's actually cached.
You can kiss goodbye to plan stability if you go that route... and
in any case I
Jim C. Nasby wrote:
On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
Tom proposed a modest roadmap type experiment a week or so ago. I'd like
to see that pursued. After all, we know of some things that are at least
at first cut stage for 8.3, and a few things high on may
57 matches
Mail list logo
