Hello Heikki,
For the kicks, I wrote a quick & dirty patch for interleaving the fsyncs, see
attached. It works by repeatedly scanning the buffer pool, writing buffers
belonging to a single relation segment at a time.
I tried this patch on the same host I used with the same "-R 25 -L 200 -T
2014-08-29 13:33 GMT-04:00 Robert Haas :
> On Wed, Aug 27, 2014 at 6:51 PM, Kouhei Kaigai wrote:
>>> > I'd like to follow this direction, and start stripping the DDL support.
>>>
>>> ...please make it so.
>>>
>> The attached patch eliminates DDL support.
>>
>> Instead of the new CREATE CUSTOM PLAN
A while back I was working on a little proposal to create a RESTful HTTP
front-end for PostgreSQL and recently I had the inspiration to work on
this. So I successfully created a background worker for PostgreSQL 9.3
that can use the SPI to list off the databases in a JSON response.
WIP on github:
Updated, rebased patch.
diff --git a/.gitignore b/.gitignore
index 681af08..823d3ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,3 +34,4 @@ lib*.pc
/pgsql.sln.cache
/Debug/
/Release/
+/tmp_install/
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 69e0824..5667943 100644
--- a/GNUmakefile.in
The general idea of this patch is not disputed, I think.
Some concerns about the details:
- Why is quote_all_identifiers left behind as a global variable?
- Shouldn't pg_dumpall also use DumpOptions?
- What about binary_upgrade?
- I think some of the variables in pg_dump's main() don't need to
On Tue, Aug 26, 2014 at 10:23 PM, Andres Freund wrote:
> On 2014-08-21 11:43:48 +0900, Sawada Masahiko wrote:
>> On Wed, Aug 20, 2014 at 9:00 PM, Jeevan Chalke
>> wrote:
>> > Hi,
>> >
>> > I have reviewed this:
>> >
>> > I have initialize cur_lineno to UINTMAX - 2. And then observed following
>>
On Sun, Aug 31, 2014 at 10:37 AM, Peter Eisentraut wrote:
> On Fri, 2014-08-29 at 10:04 +0800, Craig Ringer wrote:
> > Not just a one line patch, a one character patch.
> >
> > Use ?= instead of = in distdir assignment, so it can be overridden on
> > the command line when building dist tarballs w
Hi,
2014-08-31 8:10 GMT+09:00 Andres Freund :
> On 2014-08-31 01:50:48 +0300, Heikki Linnakangas wrote:
>
> If we're going to fsync between each file, there's no need to sort all the
> > buffers at once. It's enough to pick one file as the target - like in my
> > crude patch - and sort only the b
On Fri, 2014-08-29 at 10:04 +0800, Craig Ringer wrote:
> Not just a one line patch, a one character patch.
>
> Use ?= instead of = in distdir assignment, so it can be overridden on
> the command line when building dist tarballs with patches.
This is already possible without this patch.
You can a
On 28 August 2014 00:25, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> I haven't yet figured out how to get get into a situation where
>> heap_lock_updated_tuple_rec waits.
>
> Well, as I think I said in the first post I mentioned this, maybe there
> is no such situation. In any case, like the E
On Sat, Aug 30, 2014 at 5:05 AM, Atri Sharma wrote:
>
>
> On Saturday, August 30, 2014, Amit Kapila wrote:
>>
>> On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes
wrote:
>> >
>> > If you insert tuples with COPY into a table created or truncated in
the same transaction, at the end of the COPY it calls
On Wed, Aug 27, 2014 at 09:40:30PM -0400, Noah Misch wrote:
> > > 3. use the pg_dump binary-upgrade code when such cases happen
>
> +1. We have the convention that, while --binary-upgrade can inject catalog
> hacks, regular pg_dump uses standard, documented DDL. I like that convention
> on gene
On 2014-08-31 01:50:48 +0300, Heikki Linnakangas wrote:
> On 08/30/2014 09:45 PM, Andres Freund wrote:
> >On 2014-08-30 14:16:10 -0400, Tom Lane wrote:
> >>Andres Freund writes:
> >>>On 2014-08-30 13:50:40 -0400, Tom Lane wrote:
> A possible compromise is to sort a limited number of
> buff
On 08/30/2014 09:45 PM, Andres Freund wrote:
On 2014-08-30 14:16:10 -0400, Tom Lane wrote:
Andres Freund writes:
On 2014-08-30 13:50:40 -0400, Tom Lane wrote:
A possible compromise is to sort a limited number of
buffers say, collect a few thousand dirty buffers then sort, dump and
fsync
On Tue, Aug 26, 2014 at 10:17:05AM +0100, Dave Page wrote:
> On Tue, Aug 26, 2014 at 1:46 AM, Tom Lane wrote:
> > For the last month or so, these two buildfarm animals (which I believe are
> > the same physical machine) have been erratically failing with errors that
> > reflect low-order differenc
Heikki Linnakangas writes:
> * inet_mcv_join_selec() is O(n^2) where n is the number of entries in
> the MCV lists. With the max statistics target of 1, a worst case
> query on my laptop took about 15 seconds to plan. Maybe that's
> acceptable, but you went through some trouble to make plan
Emre Hasegeli writes:
> I updated the patch to cover semi and anti joins with eqjoinsel_semi().
> I think it is better than returning a constant.
What you did there is utterly unacceptable from a modularity standpoint;
and considering that the values will be nowhere near right, the argument
that
On 2014-08-30 14:16:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-30 13:50:40 -0400, Tom Lane wrote:
> >> A possible compromise is to sort a limited number of
> >> buffers say, collect a few thousand dirty buffers then sort, dump and
> >> fsync them, repeat as needed.
>
>
Andres Freund writes:
> On 2014-08-30 13:50:40 -0400, Tom Lane wrote:
>> A possible compromise is to sort a limited number of
>> buffers say, collect a few thousand dirty buffers then sort, dump and
>> fsync them, repeat as needed.
> Yea, that's what I suggested nearby. But I don't really li
On 2014-08-30 13:50:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-27 19:23:04 +0300, Heikki Linnakangas wrote:
> >> A long time ago, Itagaki Takahiro wrote a patch sort the buffers and write
> >> them out in order
> >> (http://www.postgresql.org/message-id/flat/20070614153758.6
Andres Freund writes:
> On 2014-08-27 19:23:04 +0300, Heikki Linnakangas wrote:
>> A long time ago, Itagaki Takahiro wrote a patch sort the buffers and write
>> them out in order
>> (http://www.postgresql.org/message-id/flat/20070614153758.6a62.itagaki.takah...@oss.ntt.co.jp).
>> The performance
Pavel Stehule writes:
> 1. I am thinking so reduction to only numeric types is not necessary -
> although we can live without it - but there are lot of non numeric
> categories: chars, date, ...
I wasn't terribly happy about that either. I still think we should
reduce this to a single polymorphi
On 2014-08-27 19:23:04 +0300, Heikki Linnakangas wrote:
> A long time ago, Itagaki Takahiro wrote a patch sort the buffers and write
> them out in order
> (http://www.postgresql.org/message-id/flat/20070614153758.6a62.itagaki.takah...@oss.ntt.co.jp).
> The performance impact of that was inconclusi
>
> While looking into this report
> http://www.postgresql.org/message-id/cf48ccfb.65a9d%tim.k...@gmail.com I
> noticed that we don't accept empty values as xml "content" values, even
> though this should apparently be allowed by the spec. Attached is a
> patch to fix it (which needs updates to xm
+ if (latency_limit)
+ printf("number of transactions above the %.1f ms latency limit: "
INT64_FORMAT "\n",
+ latency_limit / 1000.0, latency_late);
+
Any reason not to report a percentage here?
Yes: I did not thought of it.
Here is a v7, with a
Hi,
I generally want to say that having a feature like this feels *very*
helpful to me. Lots of pg development hasn't really paid attention to
anything but the final pgbench results...
On 2014-08-29 19:48:43 +0200, Fabien COELHO wrote:
> + if (latency_limit)
> + printf("number of
Kevin Grittner wrote:
> Kevin Grittner wrote:
> executor-tuplestore-relations covers parse analysis,
> planner/optimizer, and executor layers.
> 30 files changed, 786 insertions(+), 9 deletions(-)
Testing and further review found a few places that needed to add
lines for the new RTE kind that
Hi,
when profiling optimized builds (linux, gcc 4.9) it's currently
LWLockAcquireCommon() showing up, not it's callers. Instruction level
profiles show that the tests for valptr show up in profiles to some
extent. Since most callers don't need the valptr logic it seems prudent
to mark the function
On Saturday, August 30, 2014, Amit Kapila wrote:
> On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes > wrote:
> >
> > If you insert tuples with COPY into a table created or truncated in the
> same transaction, at the end of the COPY it calls heap_sync.
> >
> > But there cases were people use COPY in
On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes wrote:
>
> If you insert tuples with COPY into a table created or truncated in the
same transaction, at the end of the COPY it calls heap_sync.
>
> But there cases were people use COPY in a loop with a small amount of
data in each statement. Now it is
On Thu, Aug 28, 2014 at 11:06 PM, Alvaro Herrera
wrote:
>
> Robert Haas wrote:
>
> > Now, in the case where you are setting an overall limit, there is at
> > least an argument to be made that you can determine the overall rate
> > of autovacuum-induced I/O activity that the system can tolerate, an
On Tue, Aug 26, 2014 at 9:49 PM, Alvaro Herrera
wrote:
>
> So my proposal is a bit more complicated. First we introduce the notion
> of a single number, to enable sorting and computations: the "delay
> equivalent", which is the cost_limit divided by cost_delay. The highest
> the value is for any
32 matches
Mail list logo
