On Wednesday, February 8, 2012, Bruce Momjian wrote:
On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote:
The one other issue I ran into in following the latest pgindent
instructions was that I had to add #include stdlib.h to the
parse.c file (as included in the
On Tuesday, February 7, 2012, Peter Eisentraut wrote:
On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote:
One thing that is perhaps worth thinking about: Currently, we just
ignore missing root.crt and root.crl files. With this patch, we
still
do this, even if the user has
On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
The attached patch allows it to reuse that memory. On my meager
system it reduced the building of an index on an integer column in a
skinny 200 million row totally randomly ordered table by about 3% from
a baseline of 25
On Sat, Feb 4, 2012 at 10:06 AM, Jeff Janes jeff.ja...@gmail.com wrote:
The worst thing about the current memory usage is probably that big
machines can't qsort more than 16,777,216 tuples no matter how much
memory they have, because memtuples has to live entirely within a
single allocation,
On 07/02/12 19:58, Bruce Momjian wrote:
On Tue, Feb 07, 2012 at 05:06:18PM -0500, Greg Smith wrote:
On 02/07/2012 03:23 PM, Bruce Momjian wrote:
Where did you see that there will be an improvement in the 9.2
documentation? I don't see an improvement.
I commented that I'm hoping for an
On Wed, Feb 8, 2012 at 8:13 AM, Magnus Hagander mag...@hagander.net wrote:
On Wednesday, February 8, 2012, Bruce Momjian wrote:
On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote:
The one other issue I ran into in following the latest pgindent
instructions was that I had to add
On Wed, Feb 8, 2012 at 06:21, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
Case #1 uses the normal textcat(text, text) operator by automatically
coercing 'x' as text.
However, case #2 uses the anytextcat(anynonarray, text), which is
marked as volatile thus acts as
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
This patch uses FPIs to guard
On Wed, Feb 08, 2012 at 02:44:13PM +0900, Shigeru Hanada wrote:
(2012/02/07 23:44), Marko Kreen wrote:
On Tue, Feb 07, 2012 at 07:25:14PM +0900, Shigeru Hanada wrote:
- What is the right (or recommended) way to prevent from throwing
exceptoin in row-processor callback function? When author
(2012/02/02 18:24), Marko Kreen wrote:
I think you want this instead:
https://commitfest.postgresql.org/action/patch_view?id=769
With modified version of pgsql_fdw which uses row processor to retrieve
result tuples, I found significant performance gain on simple read-only
pgbench, though
On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 26-01-2012 06:19, Fujii Masao wrote:
Thanks for your review. Comments below.
When I compiled the source with xlogdiff.patch, I got the following warnings.
xlogfuncs.c:511:2: warning: format '%lX' expects
On mån, 2012-02-06 at 21:11 +0100, Michael Meskes wrote:
On Fri, Feb 03, 2012 at 01:15:30PM +0100, Christian Ullrich wrote:
Shouldn't these be [7]? You can have up to 6 items, plus the terminator.
I take it only keywords have to be [7], right? Committed, thanks for spotting
this.
There
2012/2/8 Pavel Golub pa...@microolap.com:
Hello, sujayr06.
You wrote:
s Hello All,
s My application has to do a real time data upload to PostgreSQL
s server.
s Every time i have to do a real time upload, i do not wish to
open
s new connection.
s I
On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp ma...@juffo.org wrote:
Patch attached (in git am format). Passes all regression tests (except
'json' which fails on my machine even on git master).
Can you provide the diffs from the json test on your machine? I don't
see any build-farm failures
It doesn't necessarily matter if we increase the size of the postgres
binary by 10%, precisely because most of that is not going to be in
play from one instant to the next. I'm thinking, in particular, of
btree index specialisations, where it could make perfect sense to go
crazy. You cannot have a
On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
This patch uses FPIs to guard
On Tue, Feb 7, 2012 at 12:43 PM, Robert Haas robertmh...@gmail.com wrote:
I've committed the numeric and varbit patches and will look at the
temporal one next.
Committed, after changing the OIDs so they don't conflict.
Here's one more case for you to ponder:
rhaas=# create table noah (i
Excerpts from Bruce Momjian's message of mié feb 08 00:58:58 -0300 2012:
As much as I hate to poo-poo a patch addition, I have to agree with
Robert Haas on this one. Renaming settings really isn't moving us
forward. It introduces a migration problem and really doesn't move us
forward in
Peter Geoghegan pe...@2ndquadrant.com writes:
It doesn't necessarily matter if we increase the size of the postgres
binary by 10%, precisely because most of that is not going to be in
play from one instant to the next.
You've heard of swapping, no? Basically what I'm hearing from you is
total
On Wed, Feb 8, 2012 at 9:38 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think that (part of) the underlying problem is that we have no clear
way to specify how much I/O do you want autovacuum to use. That's
what this patch is all about, AFAIU; it has nothing to do with
monitoring.
On Wed, Feb 8, 2012 at 8:33 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
It doesn't necessarily matter if we increase the size of the postgres
binary by 10%, precisely because most of that is not going to be in
play from one instant to the next.
As Tom says, that doesn't jive with my
On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IMO this patch is already well past the point of diminishing returns in
value-per-byte-added. I'd like to see it trimmed back to provide a fast
path for just single-column int4/int8/float4/float8 sorts. The other
cases aren't
Peter Eisentraut pete...@gmx.net writes:
if (IsUnderPostmaster)
ereport(FATAL,
(errcode(ERRCODE_SYNTAX_ERROR),
- errmsg(invalid command-line arguments for
server process),
+
On Wed, Feb 08, 2012 at 01:33:30PM +, Peter Geoghegan wrote:
It doesn't necessarily matter if we increase the size of the postgres
binary by 10%, precisely because most of that is not going to be in
play from one instant to the next. I'm thinking, in particular, of
btree index
On Wed, Feb 08, 2012 at 10:17:36AM -0500, Robert Haas wrote:
On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IMO this patch is already well past the point of diminishing returns in
value-per-byte-added. I'd like to see it trimmed back to provide a fast
path for just
On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
How do people feel about pulling text out of the SGML docs and loading
it into the database as table and column comments?
I'm not thrilled by that proposal. The length limits on comments are
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp ma...@juffo.org wrote:
Patch attached (in git am format). Passes all regression tests (except
'json' which fails on my machine even on git master).
Can you provide the diffs from the json test on your
On Wed, Feb 08, 2012 at 09:56:17AM -0500, Robert Haas wrote:
This is all fine, but what does it have to do with the current patch? I
mean, if we change vacuum to do some stuff differently, it's still going
to have to read and dirty pages and thus account for I/O.
Yeah, I drifted off
Bruce Momjian br...@momjian.us writes:
Yes, please. That would be a big help. Is there no optimization for
strings? I assume they are sorted a lot.
It seems unlikely that it'd be worth including strings, especially if
your locale is not C. This whole thing only makes sense for datatypes
On Wed, Feb 08, 2012 at 11:35:46AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Yes, please. That would be a big help. Is there no optimization for
strings? I assume they are sorted a lot.
It seems unlikely that it'd be worth including strings, especially if
your
On Wed, Feb 8, 2012 at 18:20, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp ma...@juffo.org wrote:
Patch attached (in git am format). Passes all regression tests (except
'json' which fails on my machine even on git
On 8 February 2012 15:17, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IMO this patch is already well past the point of diminishing returns in
value-per-byte-added. I'd like to see it trimmed back to provide a fast
path for just
On 02/08/2012 11:20 AM, Tom Lane wrote:
I am going to go ahead and commit the patch with the altered json
results, because IMO it is mere accident that these regression cases
were coming out with nice field labels anyway. When and if Andrew
gets the RowExpr cases fixed properly, that will
Marti Raudsepp ma...@juffo.org writes:
On Thu, Dec 22, 2011 at 18:41, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp ma...@juffo.org wrote:
PS: It seems that the min/max optimization isn't documented in the
manual (apart from release notes), so I
Andrew Dunstan and...@dunslane.net writes:
On 02/08/2012 11:20 AM, Tom Lane wrote:
I am going to go ahead and commit the patch with the altered json
results, because IMO it is mere accident that these regression cases
were coming out with nice field labels anyway. When and if Andrew
gets
On Wed, Feb 8, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Feb 08, 2012 at 10:17:36AM -0500, Robert Haas wrote:
On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
IMO this patch is already well past the point of diminishing returns in
value-per-byte-added.
On Wed, Feb 8, 2012 at 11:22 AM, Bruce Momjian br...@momjian.us wrote:
What we have now just isn't cutting it for 99% of our users, and we need
to address that if we are going to ever make any real headway here.
Why can't vacuum handle things automatically like checkpoint smoothing?
Why can't
Robert Haas robertmh...@gmail.com writes:
[ lots of numbers ]
... I just can't get excited about that. However, I
find the single-key optimizations much more compelling, for the
reasons stated above, and feel we ought to include those.
This conclusion seems sound to me, for the reasons you
On Tue, Feb 7, 2012 at 10:21 PM, Joachim Wieland j...@mcknight.de wrote:
On Tue, Feb 7, 2012 at 4:59 PM, Robert Haas robertmh...@gmail.com wrote:
It turns out that (as you anticipated) there are some problems with my
previous proposal.
I assume you're talking to Tom, as my powers of
On Wed, Feb 1, 2012 at 11:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 31.01.2012 17:35, Fujii Masao wrote:
On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.01.2012 15:32, Robert Haas wrote:
On Sat, Jan 14,
On Tue, Oct 25, 2011 at 7:37 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Oct 24, 2011 at 14:40, Magnus Hagander mag...@hagander.net wrote:
On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
How does this interact with synchronous
On 8 February 2012 17:58, Robert Haas robertmh...@gmail.com wrote:
It seems clear that the single sort-key optimizations are a much
better value per byte of code than the type-specific optimizations.
Ignoring client overhead, we get between half and two-thirds of the
benefit, and it costs us
Jay Levitt jay.lev...@gmail.com writes:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
Not sure yet about most of these, but I know the reason for this one:
2. In both 9.1 and 9.2, there is a long delay before CREATE
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jay Levitt jay.lev...@gmail.com writes:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
Not sure yet about most of these, but I know the reason for
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM there are two ways we could fix this:
1. Introduce a duplicative test at the start of gistbuild().
2. Rearrange the order of operations in index_build() so that the init
fork
On 8 February 2012 18:48, Peter Geoghegan pe...@2ndquadrant.com wrote:
I think that there may be additional benefits from making the
qsort_arg specialisation look less like a c stdlib one, like refining
the swap logic to have compile-time knowledge of the type it is
sorting. I'm thinking that
On Wed, Feb 8, 2012 at 2:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM there are two ways we could fix this:
1. Introduce a duplicative test at the start of gistbuild().
2.
On Tue, Feb 7, 2012 at 11:26 PM, Jay Levitt jay.lev...@gmail.com wrote:
[*] psql:slowcube.sql:20: ERROR: node buffer of page being split (121550)
does not exist
This looks like a bug in buffering GiST index build I've implemented during
my GSoC 2011 project. It looks especially strange with
Andrew Dunstan and...@dunslane.net writes:
OK, in this version we simply suppress creation of the TableDataInfo
object if it's not wanted.
I applied this with some further adjustments.
I actually removed the code from
makeTableDataInfo - there are only two places it gets called and doing
Robert Haas robertmh...@gmail.com writes:
I guess. I think the compelling reason to do ambuildempty first is
that it's fast. So might as well. I think you'e just going to end up
hard-wiring the assumption that ambuild happens before ambuildempty,
Well, no, because I'm proposing that both
On Wed, Feb 8, 2012 at 19:48, Tom Lane t...@sss.pgh.pa.us wrote:
I applied this patch, since I was busy applying catalog changes from you
anyway ;-).
Thanks :)
I did think of a possible reason to reject the patch: with this change,
the planner will take longer to plan queries involving
Hi
We have some tables with documents and their metadata (filename,
filetype, etc).
Most of the time we just want to get the metadata (filename, filetype,
etc) and not the document itself.
In this case it would be nice to have the metadata (which wouldn't end
up on the TOAST) on a fast array
Greg,
This is currently awaiting a check by gsmith that the 7 named extensions
do not add any new dependancies.
Are you going to investigate this? If not, I'll give it a try this weekend.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
Jay Levitt jay.lev...@gmail.com writes:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
1. In 9.1.2, inserting 10x rows takes 19x the time.
- 9.1-HEAD and 9.2 fix this; it now slows down linearly
- but: 10s
On Wed, Feb 8, 2012 at 17:13, Bruce Momjian br...@momjian.us wrote:
On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
How do people feel about pulling text out of the SGML docs and loading
it into the database as table and column comments?
I'm
On Sun, Jan 29, 2012 at 6:04 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, Jan 29, 2012 at 9:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
If I cast to a int, then I see advancement:
I'll initialise it as 0, rather than -1 and then we don't have a
problem in any circumstance.
I've
On Wed, Feb 8, 2012 at 1:48 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
That was clear from an early stage, and is something that I
acknowledged way back in September
OK, so why didn't/don't we do and commit that part first, and then
proceed to argue about the remainder once it's in?
I
Is there any problem if the double-write happens only by bgwriter or
checkpoint.
Something like whenever backend process has to evict the buffer, it will do
same as you have described that write in a double-write buffer, but
bgwriter will check this double-buffer and flush from it.
On 8 February 2012 23:33, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 8, 2012 at 1:48 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
That was clear from an early stage, and is something that I
acknowledged way back in September
OK, so why didn't/don't we do and commit that part
On Wed, Feb 8, 2012 at 1:21 PM, Robert Haas robertmh...@gmail.com wrote:
In my patch I dealt with exactly the same problem for the error
handler by creating a separate function that has a static variable (a
pointer to the ParallelState). The value is set and retrieved through
the same
On 02/08/2012 11:22 AM, Bruce Momjian wrote:
Why can't vacuum handle things automatically like checkpoint smoothing?
Why can't it detect when it is falling behind and speed up? Why can't
it see as busy background writer and slow down? Unless we answer
these questions, we are not solving the
At 2012-02-07 13:20:43 +0200, pete...@gmx.net wrote:
Should we rename the options and/or add that to the documentation, or is
the new behavior obvious and any new terminology would be too confusing?
I agree there is potential for confusion either way. I tried to come up
with a complete and
62 matches
Mail list logo
