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 n
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 pr
On Wed, Feb 8, 2012 at 1:21 PM, Robert Haas 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 function, so yes, it's
On 8 February 2012 23:33, Robert Haas wrote:
> On Wed, Feb 8, 2012 at 1:48 PM, Peter Geoghegan 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 abou
> 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 Wed, Feb 8, 2012 at 1:48 PM, Peter Geoghegan 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 think that there may
On Sun, Jan 29, 2012 at 6:04 PM, Simon Riggs wrote:
> On Sun, Jan 29, 2012 at 9:41 PM, Jeff Janes 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 specifically designed the pgbe
On Wed, Feb 8, 2012 at 17:13, Bruce Momjian wrote:
> On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
>> Bruce Momjian 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 tha
Jay Levitt 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 > 8s > 5s!
>
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 (
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 (
On Wed, Feb 8, 2012 at 19:48, Tom Lane 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 bool_and() et al,
>
Robert Haas 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 functions throw this
Andrew Dunstan 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
> it in those tw
On Tue, Feb 7, 2012 at 11:26 PM, Jay Levitt 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 following setting:
On Wed, Feb 8, 2012 at 2:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane 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
On 8 February 2012 18:48, Peter Geoghegan 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 we could usefully
Robert Haas writes:
> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane 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 is made first.
>>
>> Both
On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane wrote:
> Jay Levitt 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
Jay Levitt 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 INDEX realizes
On 8 February 2012 17:58, Robert Haas 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 just one extra copy
On Tue, Oct 25, 2011 at 7:37 PM, Magnus Hagander wrote:
> On Mon, Oct 24, 2011 at 14:40, Magnus Hagander wrote:
>> On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
>> wrote:
>>> How does this interact with synchronous replication? If a base backup that
>>> streams WAL is in progress, and you ha
On Wed, Feb 1, 2012 at 11:46 PM, Heikki Linnakangas
wrote:
> On 31.01.2012 17:35, Fujii Masao wrote:
>>
>> On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 20.01.2012 15:32, Robert Haas wrote:
On Sat, Jan 14, 2012 at 9:32 AM, Heikki Linnakangas
wr
On Tue, Feb 7, 2012 at 10:21 PM, Joachim Wieland wrote:
> On Tue, Feb 7, 2012 at 4:59 PM, Robert Haas 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 anticipation are
> actually quite limite
Robert Haas 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 stated and one
mor
On Wed, Feb 8, 2012 at 11:22 AM, Bruce Momjian 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 it detect w
On Wed, Feb 8, 2012 at 10:59 AM, Bruce Momjian 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 wrote:
>> > IMO this patch is already well past the point of diminishing returns in
>> > value-per-byte-added. I'd like to see it trimm
Andrew Dunstan 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 the RowExp
Marti Raudsepp writes:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp wrote:
>>> PS: It seems that the min/max optimization isn't documented in the
>>> manual (apart from release notes), so I didn't include any doc changes
>>> in this patch
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 s
On 8 February 2012 15:17, Robert Haas wrote:
> On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane 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/flo
On Wed, Feb 8, 2012 at 18:20, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp 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 th
On Wed, Feb 08, 2012 at 11:35:46AM -0500, Tom Lane wrote:
> Bruce Momjian 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 n
Bruce Momjian 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
that are compar
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 o
Robert Haas writes:
> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp 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-
On Tue, Feb 07, 2012 at 11:29:12PM -0500, Tom Lane wrote:
> Bruce Momjian 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
> very much
On Wed, Feb 08, 2012 at 10:17:36AM -0500, Robert Haas wrote:
> On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane 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 in
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 specialis
Peter Eisentraut writes:
> if (IsUnderPostmaster)
> ereport(FATAL,
> (errcode(ERRCODE_SYNTAX_ERROR),
> - errmsg("invalid command-line arguments for
> server process"),
> +
On Wed, Feb 8, 2012 at 9:51 AM, Tom Lane 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 going to offer
On Wed, Feb 8, 2012 at 8:33 AM, 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.
As Tom says, that doesn't jive with my experience. If you add
On Wed, Feb 8, 2012 at 9:38 AM, Alvaro Herrera
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. Right now, as has be
Peter Geoghegan 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 denial that binary
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
On Tue, Feb 7, 2012 at 12:43 PM, Robert Haas 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 interval day);
CREATE TAB
On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
> On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
> > On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
> >> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
> >> > This patch uses FPIs to guard against torn hint 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. I'm thinking, in particular, of
btree index specialisations, where it could make perfect sense to "go
crazy". You cannot have
On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp 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 off-hand...
--
2012/2/8 Pavel Golub :
> 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 want
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.
>
>
On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira
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 argument
(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 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? Whe
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
> On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
>> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
>> > On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
>
>> > This patch uses FPIs to guard against torn hint writes, e
On Wed, Feb 8, 2012 at 06:21, Tom Lane wrote:
> Marti Raudsepp 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 an optimization barrier.
On Wed, Feb 8, 2012 at 8:13 AM, Magnus Hagander 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 #include
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 h
On Sat, Feb 4, 2012 at 10:06 AM, Jeff Janes 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, which is current
On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes 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 minutes.
>
Jus
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 t
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 to the
> > > parse.c file (as included in the pg_bsd_indent-1
62 matches
Mail list logo
