My apologies if this is a duplicate. I think the attachment size was too
big.
Reference: Bruce Momjian writes: -
http://archives.postgresql.org/pgsql-committers/2007-09/msg00402.php
Other references: Boyer Moore?? -
if there is anything that I've
overlooked.
David.
-Original Message-
From: David Rowley [mailto:[EMAIL PROTECTED]
Sent: 31 August 2008 00:21
To: 'pgsql-hackers@postgresql.org'
Subject: TODO item: Implement Boyer-Moore searching (First time hacker)
Reference: Bruce Momjian writes
Moved from pgsql-patches
Tom Lane wrote:
I wrote:
I looked this over a bit and was immediately confused by one thing:
the introductory comment says that the skip table size ought to be based
on the length of the haystack, which makes sense to me, but the code is
actually initializing it
Tom Lane Wrote:
David Rowley [EMAIL PROTECTED] writes:
I've made the discussed changes. Also updated the benchmark results.
http://www.unixbeast.com/~fat/8.3_test_v1.3.xls
Applied with revisions; mostly cosmetic except for one point. I
realized after studying the code a bit more that B-M
I was just searching though the TODO list to try and find a quick one that
could be ticked off.
Under functions there is Allow substring/replace() to get/set bit values.
Does anyone have any more information about this?
Heikki Linnakangas wrote:
David Rowley wrote:
Thanks for all the reviews and suggestions.
David, could you re-run the performance tests you ran earlier? I'm
curious to know what impact switching to the simpler loop for 1-byte
pattern had.
Sure: http://www.unixbeast.com/~fat/8.3_test_v1.4
Hitoshi Harada wrote:
I made up my mind to scratch former window functions and redesigned
completely new execution model, based on the discussion with Heikki.
Attached is the v06 against HEAD today.
http://umitanuki.net/pgsql/wfv06/design.html
First off, fantastic work!
In my eyes this and WITH
Hitoshi Harada Wrote:
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
Peter Eisentraut Wrote:
If I read this right, SQL would allow writing
TABLE foo;
Interesting; I managed to find it in the spec:
Quote
4) The explicit table
TABLE table or query name
is equivalent to the table subquery
( SELECT * FROM table or query name )
/Quote
So going by that would the
All,
This is my first patch review for PostgreSQL. I did submit a patch last
commit fest (Boyer-Moore) so I feel I should review one this commit fest.
I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
best. Heikki is also reviewing this patch which makes me feel better.
that people will
probably use this method as sometimes there is little choice to get the
performance that is required.
Hitoshi Harada Wrote:
2008/11/2 David Rowley [EMAIL PROTECTED]:
Obervations:
Test 3 and 5 did not seem to make use of an index to get a sorted list
of
results. I disabled
Hitoshi Harada wrote:
Test 3 and 5 did not seem to make use of an index to get a sorted
list
of
results. I disabled enable_seqscan but the planner still failed to
choose
index_scan. Is there any reason for this? Perhaps I'm missing
something.
Hitoshi, can you take a look at this?
I wrote:
All,
This is my first patch review for PostgreSQL. I did submit a patch last
commit fest (Boyer-Moore) so I feel I should review one this commit fest.
I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
best. Heikki is also reviewing this patch which makes me
Hitoshi Harada Wrote:
although attached is the whole (split) patch.
I'm having some trouble getting these patches to patch cleanly. I think it's
because of this that I can't get postgres to compile after applying the
patch.
It errors out at tuptoaster.c some constants seem to be missing from
I've done a little testing with NTILE(). I think a check should be added to
the ntile() function in wfunc.c.
david=# select name,salary,ntile(0) over (order by salary) as n from
employees;
ERROR: floating-point exception
DETAIL: An invalid floating-point operation was signaled. This probably
Using one of my original test tables I'm testing windowing functions with a
GROUP BY.
The following query works as I would expect.
-- Works
SELECT department,
SUM(Salary),
ROW_NUMBER() OVER (ORDER BY department),
SUM(SUM(salary)) OVER (ORDER BY department)
FROM employees
Hitoshi Harada wrote:
I'm glad to hear that. Actually thanks to git it is quite easy for me
to merge my own repository with the HEAD. It tells me which lines are
new coming and which lines I modified are newer than else in CVS. This
is my first project where I use git (and I am not guru of cvs
I'm having a little trouble understanding the standard for NTH_VALUE(). I
would have assumed that NTH_VALUE(name,1) would return the first name in the
window. The current patch is using 0 for the first.
Here is the paragraph I'm reading in the standard:
The nth-value function takes an arbitrary
Hitoshi Harada wrote:
I recreate the patch against current HEAD, in the git it's here:
http://git.postgresql.org/?p=postgresql.git;a=commit;h=f88970d3c6fb9f99543
d873bb7228f4c057c23e0
I tested `patch -p1` with the attached and succeeded to make it work
cleanly. It seems to me that this
Hitoshi Harada wrote:
I found how to do it, though it's only on the case you gave. Thinking
about the planner optimization of the Window nodes (and its attached
Sort nodes), we must consider the execution order of more than one
node. In the test case we only take care of only one window, but
I've been trying to think of a use case for using ROW_NUMBER() with no ORDER
BY in the window clause.
Using the example table I always seem to be using, for those who missed it
in other threads.
create table employees (
id INT primary key,
name varchar(30) not null,
department varchar(30)
Hitoshi Harada wrote:
I found how to do it, though it's only on the case you gave. Thinking
about the planner optimization of the Window nodes (and its attached
Sort nodes), we must consider the execution order of more than one
node. In the test case we only take care of only one window, but
Hitoshi Harada wrote:
The spec says: The ROW_NUMBER function computes the sequential row
number,
starting with 1 (one) for the first row, of the row within its window
partition according to the window ordering of the window.
I'm just not sure if we should block this or not.
Does
Josh Berkus Wrote:
I would suggest submitting it to pgsql-jobs.
Except that it's not a job offer - it's more of a solicitation for
implementation of something, so I'm not sure that's the right place
either.
No, but that's where the right people would see it.
Realistically, this
Hitoshi Harada wrote:
david=# explain select date,lag(date,1) over (order by date) from
meter_Readings order by date;
QUERY PLAN
I wrote:
All,
This is my first patch review for PostgreSQL. I did submit a patch last
commit fest (Boyer-Moore) so I feel I should review one this commit fest.
I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
best. Heikki is also reviewing this patch which makes me
Gregory Stark wrote:
So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
T-SQL code to Postgres and got this. Thought others might find it amusing.
WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
SELECT IX, IY, X::float, Y::float, X::float, Y::float, 0
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
-- The following query gives incorrect results on the
-- maxhighbid column
SELECT auctionid,
category,
description,
highestbid,
reserve,
MAX(highestbid) OVER (ORDER BY auctionid
On 26/11/2008, Hitoshi Harada [EMAIL PROTECTED] wrote:
2008/11/26 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
-- The following query gives incorrect results on the
-- maxhighbid column
SELECT auctionid,
category
I wrote:
Hmm, did you apply the latest patch correctly? My build can produce
right results, so I don't see why it isn't fixed. Make sure the lines
around 2420-2430 in planner.c like:
/*
* must copyObject() to avoid args concatenating
with
-Original Message-
From: Heikki Linnakangas [mailto:[EMAIL PROTECTED]
Sent: 26 November 2008 09:09
To: Hitoshi Harada
Cc: David Rowley; pgsql-hackers@postgresql.org
Subject: Re: Windowing Function Patch Review - Standard Conformance
Hitoshi Harada wrote:
2008/11/26 David Rowley
I wrote:
I was also reading over the standard tonight. I've discovered that the
OFFSET in LEAD() and LAG() is optional. It should default to 1 if it is
not present. Oracle seems to support this.
SQL2008 says:
If lead or lag function is specified, then:
i) Let VE1 be lead or lag extent
Hitoshi Harada wrote:
I tested the spool performance with David's earlier bigtable:
CREATE TABLE bigtable (
id SERIAL NOT NULL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL
);
-- about 383MB of data
INSERT INTO bigtable (timestamp)
SELECT NOW() + (CAST(RANDOM() * 10 AS INT) || '
Hitoshi Harada Wrote:
2008/12/3 Hitoshi Harada [EMAIL PROTECTED]:
I am randomly trying some issues instead of agg common code (which I
now doubt if it's worth sharing the code), so tell me if you're
restarting your hack again. I'll send the whole patch.
Attached is the updated patch,
2008/12/7 Hitoshi Harada [EMAIL PROTECTED]:
2008/12/7 Hitoshi Harada [EMAIL PROTECTED]:
2008/12/6 David Rowley [EMAIL PROTECTED]:
the time where the community can test further by committing this patch.
Agree. I'll send the latest patch and finish my work for now.
Here's the patch, including
Josh Williams wrote:
Hi folks,
Was recently poked and reminded that this patch may be of interest to
the community. It was mostly done as an academic exercise, just to see
how it works, and so it has a rather hackish feel. The patch adds the
sequence owner, if available, to psql's \d
Robert Haas Wrote:
Hmm. I'm not able to reliably detect a performance difference between
unpatched CVS HEAD (er... git master branch) and same with spcoptions-
v2.patch applied. I figured that if there were going to be an impact,
it would be most likely to manifest itself in a query that
Hitoshi Harada wrote:
I tested on Oracle 10.2.0, and the results are:
select depname, empno, salary,
lead(salary, 1) over (order by salary),
lag(salary, 1) over (order by salary),
first_value(salary) over (order by salary),
last_value(salary) over (order by salary)
from empsalary;
Hitoshi Harada wrote:
I tested on Oracle 10.2.0, and the results are:
select depname, empno, salary,
lead(salary, 1) over (order by salary),
lag(salary, 1) over (order by salary),
first_value(salary) over (order by salary),
last_value(salary) over (order by salary)
from empsalary;
Tom Lane Wrote:
I've spent quite a bit of time reviewing the window functions patch,
and I think it is now ready to commit, other than the documentation
(which I've not looked at yet at all). Attached is my current patch
against HEAD, sans documentation. This incorporates the recently
Hitoshi Harada wrote:
WITH RECURSIVE bom AS (
SELECT parentpart,childpart,quantity,ROW_NUMBER() OVER (ORDER BY
parentpart DESC) rn
FROM billofmaterials
WHERE parentpart = 'KITCHEN'
UNION ALL
SELECT b.parentpart,b.childpart,b.quantity,ROW_NUMBER() OVER (ORDER BY
parentpart ASC)
Tom Lane Wrote:
The core window-functions patch is now committed and ready for wider
testing. However, there are a number of unfinished items, at least
some of which I'd like to see addressed before 8.4 release. In rough
order of importance:
* Support creation of user-defined window
Tom Lane Wrote:
Well, this certainly demonstrates that the check I added to
parseCheckAggregates is wrongly placed, but I'm not sure we really
need to forbid the case. David's example query seems to give sane
answers once the bug in begin_partition is fixed:
parentpart | childpart |
Tom Lane Wrote:
Actually, it's not ambiguous according to our interpretation of ORDER BY
clauses: the first attempt is to match an output column name, so it's
seizing on the first SELECT column (b.parentpart) as being the intended
sort key for parentpart, and similarly for childpart. You'd
I had an email today about an old bug that I reported back in July 2008.
http://archives.postgresql.org/pgsql-bugs/2008-07/msg00026.php
I didn't receive any response at the time and I didn't really follow it up.
My report contained a full re-creation script to reproduce the problem and
I've been putting a little bit of thought into how to go about testing the
performance of this patch. From reading the previous threads quite a bit of
testing was done with a certain data set where all that tested found it to
be a big winner with staggering performance gains with the skewed
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 10 February 2009 22:30
To: David Rowley
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Bug #4284
David Rowley dgrow...@gmail.com writes:
My report contained a full re-creation script to reproduce the problem
and
tonight I'm
Tom Lane Wrote:
David Rowley dgrow...@gmail.com writes:
My report contained a full re-creation script to reproduce the problem
and
tonight I'm having the same problem with CVS Head. To my untrained eye
it
looks like the planner is not properly pushing down the row count.
It looks more
!values of varnamecommit_siblings/varname should be used *in* such
cases,
Thanks for doing all the benchmarks too. Good to see such a range of
different hardware tested.
Regards
David Rowley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
and agree 100%, but I'm really looking forward to when we can *one day*
have the planner make use of an eager MV to optimise a query!
Regards
David Rowley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org
to look
into how hard it would be to implement this, but I thought I'd throw it out
there to collect some comments on the idea.
Regards
David Rowley
BEGIN WORK;
CREATE TABLE products (
productid INT NOT NULL,
product_code VARCHAR(64) NOT NULL,
PRIMARY KEY(productid)
);
CREATE
David Rowley
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 07 December 2012 06:22
To: Simon Riggs
Cc: David Rowley; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Functional dependency in GROUP BY through JOINs
Simon Riggs si...@2ndquadrant.com writes:
On 5 December 2012 23:37, David Rowley
From: Simon Riggs [mailto:si...@2ndquadrant.com]
Sent: 07 December 2012 05:44
To: David Rowley
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Functional dependency in GROUP BY through JOINs
On 5 December 2012 23:37, David Rowley dgrowle...@gmail.com wrote:
Though this plan
my application was broken during an testing an upgrade to
9.3 than somewhere down the line. I can't imagine renaming a constraint to
upgrade to 9.3 is going to be a showstopper for anyone.
Perhaps the release notes can contain a query to allow users to check this
pre-upgrade.
Regards
David Rowley
David Rowley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if such a thing was worth the extra overhead.
Regards
David Rowley
this patch you can do things like have %10u %-10d in your
log_line_prefix which will include spaces to give the option the number you
specify as the minimum width. Left and right aligning is supported.
Let this be the thread to collect consensus to whether this needed and
useful.
Regards
David
On Tue, Aug 27, 2013 at 7:55 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 08/27/2013 05:06 AM, David Rowley wrote:
Heikki wrote that it might be useful to allow formatting in the
log_line_prefix here
http://www.postgresql.org/message-id/5187cadb.50...@vmware.com
I thought I'd take
(Forgot to copy list)
From: David Rowley [mailto:dgrowle...@gmail.com]
Sent: 19 September 2013 22:35
To: Albe Laurenz
Subject: Re: REVIEW: Allow formatting in log_line_prefix
Hi Laurenz,
Thanks for the review.
Please see my comments below and the updated patch attached.
On Thu, Sep
On Fri, Sep 20, 2013 at 12:48 AM, Peter Eisentraut pete...@gmx.net wrote:
Something is weird in your latest patch. The header is:
diff -u -r b/postgresql/doc/src/sgml/config.sgml
a/postgresql/doc/src/sgml/config.sgml
--- b/postgresql/doc/src/sgml/config.sgml 2013-09-09
On Sat, Sep 21, 2013 at 7:18 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz laurenz.a...@wien.gv.at
wrote:
David Rowley wrote:
I moved the source around and I've patched against it again. New patch
attached.
Thank you, marked as ready
On Tue, Sep 24, 2013 at 5:16 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 20, 2013 at 11:28 PM, David Rowley dgrowle...@gmail.com
wrote:\
I put the above results into the attached spreadsheet. On my intel i5
laptop
I'm seeing a slow down of about 1 second per million queries
On Wed, Sep 25, 2013 at 6:25 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
David Rowley escribió:
I do see a 15-18% slow down with the patched version, so perhaps
I'll need
On Wed, Sep 25, 2013 at 1:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 24, 2013 at 5:04 AM, David Rowley dgrowle...@gmail.com
wrote:
So... I guess the question that I'd ask is, if you write a PL/pgsql
function that does RAISE NOTICE in a loop a large number of times, can
On Thu, Sep 26, 2013 at 4:57 AM, Peter Eisentraut pete...@gmx.net wrote:
On 9/25/13 4:46 AM, David Rowley wrote:
Please find attached the new patch ... version v0.5 and also updated
benchmark results.
Please fix compiler warnings:
elog.c: In function ‘log_line_prefix.isra.3’:
elog.c
On Fri, Sep 27, 2013 at 4:44 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Sep 25, 2013 at 4:46 AM, David Rowley dgrowle...@gmail.com
wrote:
Ok, I think I've managed to narrow the performance gap to just about
nothing
but noise, though to do this the code is now a bit bigger. I've
On Fri, Sep 27, 2013 at 10:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 26, 2013 at 5:18 PM, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Sep 26, 2013 at 3:55 PM, David Rowley dgrowle...@gmail.com
wrote:
I think I must have forgot to save it before I emailed
replaces appendStringInfo with appendStringInfoString where possible would
be welcomed by the community. Also would using
appendStringInfoStringConst() be going 1 step too far?
Regards
David Rowley
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley dgrowle...@gmail.com wrote:
I did some benchmarking earlier in the week for the new patch which was
just commited to allow formatting in the log_line_prefix string. In version
0.4 of the patch there was some performance regression as I was doing
On Sat, Sep 28, 2013 at 11:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 28.09.2013 12:44, David Rowley wrote:
The macro for test 4 was as follows:
#define appendStringInfoStringConst(**buf, s) appendBinaryStringInfo(buf,
(s), sizeof(s)-1)
If that makes any difference
On Sat, Sep 28, 2013 at 11:11 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 28.09.2013 12:44, David Rowley wrote:
The macro for test 4 was as follows:
#define appendStringInfoStringConst(**buf, s) appendBinaryStringInfo(buf,
(s), sizeof(s)-1)
If that makes any difference
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley dgrowle...@gmail.com wrote:
I did some benchmarking earlier in the week for the new patch which was
just commited to allow formatting in the log_line_prefix string. In version
0.4 of the patch there was some performance regression as I was doing
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
PANIC: space reserved for WAL record does not match what was
On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-10-05 01:05:37 +1300, David Rowley wrote:
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG: database system was shut down at 2013-10-05 00:43:33 NZDT
LOG: database
On Sat, Oct 5, 2013 at 1:34 AM, David Rowley dgrowle...@gmail.com wrote:
On Sat, Oct 5, 2013 at 1:19 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-10-05 01:05:37 +1300, David Rowley wrote:
In HEAD of 9.4 I'm getting the following:
D:\9.4\binpostgres.exe -D d:\9.4\data
LOG
record table with 6 columns.
Regards
David Rowley
pg_dump_colinsert_v0.1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Oct 5, 2013 at 6:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Oct 4, 2013 at 11:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Here's a small patch which greatly increases the speed
On Wed, Oct 9, 2013 at 5:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund and...@2ndquadrant.com
wrote:
Could it be
\pg_archivecleanup.vcxproj]
Regards
David Rowley
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Mon, Oct 14, 2013 at 9:45 PM, David Rowley dgrowle...@gmail.com wrote:
On Sat, Oct 12, 2013 at 2:58 AM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
Peter Eisentraut escribió:
On Tue, 2013-09-17 at 15:13 +0500, Asif Naeem wrote:
I did put some time review the patch, please see my
On Tue, Oct 15, 2013 at 9:48 AM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2013-10-14 at 23:08 +1300, David Rowley wrote:
Looks like something like:
#ifndef WIN32
#define HAVE_VA_COPY 1
#endif
would need to be added to asprintf.c, but also some work needs to be
done
On Tue, Oct 15, 2013 at 8:00 PM, Asif Naeem anaeem...@gmail.com wrote:
On Tue, Oct 15, 2013 at 10:55 AM, David Rowley dgrowle...@gmail.comwrote:
Though this is not yet enough to get the windows build work with me...
I'm still getting link failures for isolationtester.c
D:\Postgres\c
are in
the macro at all? Can a compiler not decide for itself which type it should
be using?
Regards
David Rowley
But if we're bent on minimizing the use of 64-bit arithmetic on 32-bit
systems, then presumably I should instead go back and retrofit that
patch to use Size rather than uint64
just by changing the 128 into 12800 and
compiling, vcregress check worked after that.
Regards
David Rowley
I have a lot of other gripes about this whole patch, but they can
wait till tomorrow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, Oct 23, 2013 at 4:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. As a separate matter, it might be useful to revise stringinfo.c
and the asprintf code so that *if* the returned value is larger than the
given buffer size, we use it as a guide to resizing, avoiding the possible
need
Hi,
I'm just looking at the changed code in commit
3147acd63e0135aff9a6c4b01d861251925d97d9 and I'm wondering if we should
perhaps test the performance of this before assuming too much that it is an
improvement. I'm a bit concerned that now if there is not enough space in
the buffer that we only
On Sun, Oct 27, 2013 at 3:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
I'm just looking at the changed code in commit
3147acd63e0135aff9a6c4b01d861251925d97d9 and I'm wondering if we should
perhaps test the performance of this before assuming too much
On Mon, Sep 30, 2013 at 10:10 PM, David Rowley dgrowle...@gmail.com wrote:
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley dgrowle...@gmail.comwrote:
I did some benchmarking earlier in the week for the new patch which was
just commited to allow formatting in the log_line_prefix string
applications and allocates memory differently... Is this
the only reason or is there some other special reason for this function
that I can't think of?
If someone wants to give me some guidance on how or if all this should
re-factored, I'll happily supply a patch.
Regards
David Rowley
On Sat, Nov 2, 2013 at 2:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
Tom commited some changes to appendStringInfoVA a few weeks ago which
allows it to return the required buffer size if the current buffer is not
big enough.
On looking
the catalog could be queried to see which order these
columns should be displayed in.
For reference I've attached the script I used for testing this.
I'd like to implement this as a project, but before I start any work on it
I'd just like to find out other people's thoughts on it.
Regards
David Rowley
On Mon, Nov 4, 2013 at 3:14 AM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
David Rowley escribió:
I've just been looking at how alignment of columns in tuples can make the
tuple larger than needed.
This has been discussed at length previously, and there was a design
proposed to solve
Attached is a small patch which fixes the unused variable warning in the
visual studios build. Seems like VS does not
support __attribute__((unused)) but looks like all other places we must
assign to the variable.
Regards
David Rowley
unused_variable.patch
Description: Binary data
--
Sent
): warning C4113: 'void
(__cdecl *)(void)' differs in parameter lists from 'init_function'
[D:\Postgres\b\pg_regress_ecpg.vcxproj]
1 Warning(s)
The attached fixes it.
Regards
David Rowley
windows_compiler_warning.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
On Sat, Nov 9, 2013 at 7:29 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Nov 7, 2013 at 11:43 AM, David Rowley dgrowle...@gmail.com
wrote:
Attached is a small patch which fixes the unused variable warning in the
visual studios build. Seems like VS does not support
__attribute__
values in a hash
table for each backend should still be a win even if/when the single table
stuff gets implemented.
Regards
David Rowley
CREATE FUNCTION create_seq(n integer) RETURNS integer
LANGUAGE plpgsql
AS $$
BEGIN
WHILE n 0 LOOP
EXECUTE 'CREATE SEQUENCE test' || CAST(n
David Rowley
diff --git a/contrib/pageinspect/fsmfuncs.c b/contrib/pageinspect/fsmfuncs.c
index d0d105f..a91ff22 100644
--- a/contrib/pageinspect/fsmfuncs.c
+++ b/contrib/pageinspect/fsmfuncs.c
@@ -56,5 +56,5 @@ fsm_page_contents(PG_FUNCTION_ARGS)
}
appendStringInfo(sinfo
On Sun, Nov 3, 2013 at 3:18 AM, David Rowley dgrowle...@gmail.com wrote:
I'm low on ideas on how to improve things much around here for now, but
for what it's worth, I did create a patch which changes unnecessary calls
to appendPQExpBuffer() into calls to appendPQExpBufferStr() similar
.
I'll continue with my analysis, but perhaps posting this early will bring
something to light which I've not yet realised.
Regards
David Rowley
1 - 100 of 902 matches
Mail list logo
