David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
What other patches would people like to try maintaining this way until
commitfest?
It looks like gitosis is a good way to grant
On Tue, Jun 24, 2008 at 07:09:41AM +0200, Tino Wildenhain wrote:
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
What other patches would people like to try maintaining this
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
it's done for GiST and GIN indexes.
--
Teodor Sigaev
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we were just going to disable it.
I believe so. This
Hi,
From: David Fetter [EMAIL PROTECTED]
Subject: [HACKERS] Git Repository for WITH RECURSIVE and others
Date: Mon, 23 Jun 2008 21:38:11 -0700
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
Thank you very
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of RAM
for my main PostgreSQL system that I manage seems like a drop in the
bucket. Even if 40% of pg_class_relname and pg_proc_proname indices was
saved - we're talking about 154 Kbytes saved on both those
On Tue, 2008-06-24 at 12:14 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
I think you want to see the distribution of execution times for
particular queries without needing to log *every* execution, including
parameters. I think I understand now what you are asking
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
What other patches would people like to try maintaining this way until
commitfest?
It looks like gitosis is a good way to
Yes.
As in the cygwin build does build. Nobody really has verified if the fix
is needed there. But frankly, if you are likely to care about the
effects of this issue, you won't be running cygwin anyway. It's mostly a
dead platform for postgresql anyway, AFAICS we only keep it building for
legacy
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
Yes.
As in the cygwin build does build. Nobody really has verified if the fix
is needed there. But frankly, if you are likely to care about the
effects of this issue, you won't be running cygwin anyway. It's mostly a
Shane Ambler wrote:
My question is whether this is limited to system catalogs? or will this
benefit char() index used on any table? The second would make it more
worthwhile.
char(n) fields are already stored as variable-length on disk. This isn't
applicable to them.
--
Heikki Linnakangas
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping support would be an
option. I would check this for
Alex Hunsaker wrote:
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we were just going to disable
Kenneth Marshall wrote:
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping support would be an
The case I am referring to has a developer clause that allows
Cygwin applications to be used for development only. I agree that
the policy is odd.
Ken
On Tue, Jun 24, 2008 at 02:35:50PM +0200, Magnus Hagander wrote:
Kenneth Marshall wrote:
One motivation for keeping it working on Cygwin, is
Magnus Hagander wrote:
Kenneth Marshall wrote:
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many resources to support, then dropping
Andrew Dunstan wrote:
Magnus Hagander wrote:
Kenneth Marshall wrote:
One motivation for keeping it working on Cygwin, is that in some
environments it is not allowed to install native Windows apps but
they allow the use of the Cygwin environment. Of course if it takes
too many
Teodor Sigaev [EMAIL PROTECTED] writes:
dead easy to implement this: effectively, we just decree that the
index column storage type for NAME is always CSTRING. Because the
Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
it's done for GiST and GIN indexes.
Hmm
On Tue, Jun 24, 2008 at 03:26:36PM +0900, Yoshiyuki Asaba wrote:
Hi,
From: David Fetter [EMAIL PROTECTED]
Subject: [HACKERS] Git Repository for WITH RECURSIVE and others
Date: Mon, 23 Jun 2008 21:38:11 -0700
With lots of help from Greg Sabino Mullane, I've set up a git
repository for
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
What other patches would people like to try
Shane Ambler wrote:
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of
RAM for my main PostgreSQL system that I manage seems like a drop in
the bucket. Even if 40% of pg_class_relname and pg_proc_proname
indices was saved - we're talking about 154 Kbytes
Josh Berkus wrote:
Shane Ambler wrote:
Mark Mielke wrote:
Not that I disagree with your change, but 5 Mbytes in 4 Gbytes of
RAM for my main PostgreSQL system that I manage seems like a drop in
the bucket. Even if 40% of pg_class_relname and pg_proc_proname
indices was saved - we're talking
Alex Hunsaker wrote:
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we were just going to disable it.
David Fetter wrote:
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
http://git.postgresql.org/.
What other patches would people like to
Joshua D. Drake wrote:
Alex Hunsaker wrote:
On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I would like to get do this without adding a new --use-statement-timeout
flag. Is anyone going to want to honor statement_timeout during
pg_dump/pg_restore? I thought we
On Tue, 2008-06-24 at 07:55 -0700, David Fetter wrote:
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
Unfortunately, the requirements have also been raised a bit (such as
allowing a user to delegate access to another user)
Who raised
On Tue, Jun 24, 2008 at 09:21:27AM -0700, Joshua D. Drake wrote:
On Tue, 2008-06-24 at 07:55 -0700, David Fetter wrote:
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
Unfortunately, the requirements have also been raised a bit
(such as
Hackers,
Hey! So far, a sum total of *2* people have signed up to be assigned
reviewers, and one of them I put down myself. If only Greg and Alvaro
are available to review patches, no wonder our commit fests take so long!
At the developer meeting, we determined that one thing needed to
On Tue, 2008-06-24 at 09:27 -0700, David Fetter wrote:
On Tue, Jun 24, 2008 at 09:21:27AM -0700, Joshua D. Drake wrote:
On Tue, 2008-06-24 at 07:55 -0700, David Fetter wrote:
Lastly, you could also perhaps take the 10 seconds it takes to find
this page:
I recently mentioned I am speaking in New York City tonight. I am also
speaking about open source in Massachusetts in July; see my events web
page for details on both events:
http://momjian.us/main/events.html
Also, I assume people like these details posted to hackers and advocacy,
but
On Tue, Jun 24, 2008 at 05:27:38PM +0200, Magnus Hagander wrote:
David Fetter wrote:
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH RECURSIVE patches on
Well I will grant that I don't know that there is a better forum because
we don't have a [EMAIL PROTECTED] :) but I am pretty certain that
discussion of the Git repo administration doesn't have much to do with
-hackers.
How about some generic list? [EMAIL PROTECTED] or something like
Josh Berkus wrote:
Hackers,
Hey! So far, a sum total of *2* people have signed up to be assigned
reviewers, and one of them I put down myself. If only Greg and Alvaro
are available to review patches, no wonder our commit fests take so long!
Oh, also -- you don't have to be a committer to
On Tue, Jun 24, 2008 at 02:58:38PM -0300, Marc G. Fournier wrote:
Well I will grant that I don't know that there is a better forum
because we don't have a [EMAIL PROTECTED] :) but I am pretty
certain that discussion of the Git repo administration doesn't have
much to do with -hackers.
How
Hello,
I am trying to compile libpq.dll with MSVC 2003 on windows, using
postgresql-8.3.3, but I get the following compile error:
Creating library .\Release\libpqdll.lib and object .\Release
\libpqdll.exp
libpq.lib(dirmod.obj) : error LNK2019: unresolved external symbol
__dosmaperr r
David Fetter wrote:
On Tue, Jun 24, 2008 at 05:27:38PM +0200, Magnus Hagander wrote:
David Fetter wrote:
On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
David Fetter wrote:
Folks,
With lots of help from Greg Sabino Mullane, I've set up a git
repository for the WITH
The way I read it, the current btree index stores the index value and the
TID of every tuple having that value. When you have a table with three
columns, you index one of them and you get an index which is practically as
large as the table itself.
Supposing the table is generally or strictly
On Tue, Jun 24, 2008 at 4:34 PM, Jeffrey Baker [EMAIL PROTECTED] wrote:
Supposing the table is generally or strictly ordered by the column to be
indexed, it would be more compact if the index stored ranges of tuples.
Instead of storing the TID of every tuple with that value, the index would
On Mon, Jun 23, 2008 at 07:30:53PM -0400, Bruce Momjian wrote:
daveg wrote:
On Mon, Jun 23, 2008 at 06:51:28PM -0400, Bruce Momjian wrote:
Alex Hunsaker wrote:
On Wed, Apr 16, 2008 at 4:54 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Joshua D. Drake escribi?:
That is
Jeffrey Baker írta:
The way I read it, the current btree index stores the index value and
the TID of every tuple having that value. When you have a table with
three columns, you index one of them and you get an index which is
practically as large as the table itself.
Supposing the table is
On Tue, Jun 24, 2008 at 1:59 PM, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
Jeffrey Baker írta:
The way I read it, the current btree index stores the index value and
the TID of every tuple having that value. When you have a table with
three columns, you index one of them and you get an
Mark Mielke wrote:
saved - we're talking about 154 Kbytes saved on both those indices
combined. Minor? Major? I bet I wouldn't notice unless my database
requirements used up all RAM, and even then I'm suspecting it wouldn't
matter except for border line cases (like all pages required for
daveg [EMAIL PROTECTED] writes:
lock-timeout sets statement_timeout to a small value while locks are being
taken on all the tables. Then it resets it to default. So it could reset it
to whatever the new default is.
reset to default is *surely* not the right behavior; resetting to the
setting
Jeffrey Baker írta:
On Tue, Jun 24, 2008 at 1:59 PM, Zoltan Boszormenyi [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Jeffrey Baker írta:
The way I read it, the current btree index stores the index
value and
the TID of every tuple having that value. When you have a
Jeffrey Baker [EMAIL PROTECTED] writes:
I'm quite aware of the problems of maintaining such a table and index, but
the fact is that data warehouse type tables may never be updated after being
created. The particular application I'm struggling with does a SELECT ...
INTO ... ORDER BY to make
On Tue, Jun 24, 2008 at 2:38 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
I'm quite aware of the problems of maintaining such a table and index,
but
the fact is that data warehouse type tables may never be updated after
being
created. The particular
Jeffrey Baker [EMAIL PROTECTED] writes:
For this query, work_mem is 100MB and maintenance_work_mem is 1GB, on a
system with 8GB of memory. Notably I just installed a new storage subsystem
and upgraded to 8.3.1 less than a week ago, so my experience with this
instance is somewhat limited.
On Tue, Jun 24, 2008 at 4:54 PM, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
Creating the table in this case takes half an
hour and then indexing it requires almost an hour.
These numbers seem to me to be pretty strong evidence
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Now, *why* it is a mistake is interesting to speculate about, but
let's confirm the theory first.
Could this be related to hint bit rewrites during indexing?
If so, changing maintenance_work_mem won't improve the
On Tue, Jun 24, 2008 at 3:08 PM, Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Now, *why* it is a mistake is interesting to speculate about, but
let's confirm the theory first.
Could this be related to hint bit rewrites
Magnus Hagander wrote:
More to the point: I thought this had been tested. I will test it today
so we can put this whole thread to rest.
IIRC it was only tested insofar that it doesn't actually break. Not if
it returns proper results.
I have tested it using the suggested script
On Tue, Jun 24, 2008 at 05:34:50PM -0400, Tom Lane wrote:
daveg [EMAIL PROTECTED] writes:
lock-timeout sets statement_timeout to a small value while locks are being
taken on all the tables. Then it resets it to default. So it could reset it
to whatever the new default is.
reset to
On Tue, Jun 24, 2008 at 3:50 PM, Jonah H. Harris [EMAIL PROTECTED] wrote:
On Tue, Jun 24, 2008 at 4:34 PM, Jeffrey Baker [EMAIL PROTECTED] wrote:
Supposing the table is generally or strictly ordered by the column to be
indexed, it would be more compact if the index stored ranges of tuples.
Hi.
It is strange...
Problem is not reproduced although I use VC2005.
The result of my nmake -f win32.mak is this.
...
Microsoft (R) Manifest Tool version 5.2.3790.2014
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
cd ..\..
echo All Win32 parts have been built!
daveg [EMAIL PROTECTED] writes:
Are we talking about the same patch?
Maybe not --- I thought you were talking about a backend-side behavioral
change.
Because I don't know what you are
refering to with timer management code and scheduling the interrupt in
the context of pg_dump.
I'm not sure
Jeffrey Baker [EMAIL PROTECTED] writes:
I guess nobody has any interest in my proposal, only in the departure of my
described experience from expected behavior :-(
Well, we certainly should try to understand the unexpected behavior
in detail before we consider solutions. Per Sir A.C. Doyle, it
On Tue, Jun 24, 2008 at 10:41:07PM -0400, Tom Lane wrote:
daveg [EMAIL PROTECTED] writes:
Are we talking about the same patch?
Maybe not --- I thought you were talking about a backend-side behavioral
change.
Because I don't know what you are
refering to with timer management code and
57 matches
Mail list logo
