Hi,
I've been working on new pgstattuple function to allow
block sampling [1] in order to reduce block reads while
scanning a table. A PoC patch is attached.
[1] Re: [RFC] pgstattuple/pgstatindex enhancement
On Mon, Jul 22, 2013 at 8:48 PM, Greg Smith g...@2ndquadrant.com wrote:
And I can't get too excited about making this as my volunteer effort when I
consider what the resulting credit will look like. Coding is by far the
smallest part of work like this, first behind coming up with the design in
Hi,
Anchovy is failing on 9.1 and earlier for quite some time now:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovybr=REL9_1_STABLE
The commit at that date looks rather unconspicuous. Looking at the
'config' section reveals the difference between the failing
W dniu 23.07.2013 06:22, David Fetter pisze:
What problem or problems did you notice, and what did you change to
fix them?
UPDATE ... FROM generated ERROR: variable not found in subplan
target lists. I've added some workaround in add_vars_to_targetlist:
- if it is an after - simple change
On Mon, Jul 22, 2013 at 10:59 PM, Greg Stark st...@mit.edu wrote:
On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
revagade.sam...@gmail.com wrote:
for example:
if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12
setting's for particular server will be:
considering
On 2013-07-23 09:11:00 +0200, Andres Freund wrote:
Hi,
Anchovy is failing on 9.1 and earlier for quite some time now:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovybr=REL9_1_STABLE
The commit at that date looks rather unconspicuous. Looking at the
'config' section reveals the
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote amitlangot...@gmail.com wrote:
Hello,
While understanding the effect of maintenance_work_mem on time taken
by CREATE INDEX, I observed that for the values of
maintenance_work_mem less than the value for which an internal sort is
performed, the
On 2013-04-29 23:37:43 -0400, Peter Eisentraut wrote:
On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote:
The reason I'm thinking it's a good idea is that it would expose any
remaining places where we have nominally var-length arrays embedded in
larger structs. Now that I've seen the
On 2013-07-22 13:50:08 -0400, Robert Haas wrote:
On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund and...@2ndquadrant.com wrote:
The git tree is at:
git://git.postgresql.org/git/users/andresfreund/postgres.git branch
xlog-decoding-rebasing-cf4
Magnus Hagander wrote:
In that case, doesn't this patch break Windows? We no longer do the
anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP.
Don't we need to keep the ldap_simple_bind() call in the Windows case,
or break it up so the call to ldap_sasl_bind_s() is moved
Hi,
I've been trying to diagnose a severe performance regression we've been
having in one of our plpgsql procedures.
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
So here is
On 07/16/2013 09:14 PM, I wrote:
But okay, you're saying we *have* and *want* a guarantee that even a
superuser cannot execute arbitrary native code via libpq (at least in
default installs w/o extensions).
I stand corrected and have to change my position, again. For the record:
We do not have
On 7/23/13 2:16 AM, Satoshi Nagayasu wrote:
I've been working on new pgstattuple function to allow
block sampling [1] in order to reduce block reads while
scanning a table. A PoC patch is attached.
Take a look at all of the messages linked in
Hello all,
don't know much about pg_upgrade implementation so I rather asking here before
I start trying the process once again with debugging and observing deeply
the code.
I tried to setup our postgresql RPM to package pg_upgrade in version
8.4.13 to automatize post-rpm-upgrade update of
Hi all,
I haven't given this a lot of thought, but it struck me that when
rebuilding tables (be it for a restore process, or some other operational
activity) - there is more often than not a need to build an index or two,
sometimes many indexes, against the same relation.
It strikes me that in
On Tuesday, July 23, 2013 12:02 AM Greg Smith wrote:
The v3 patch applies perfectly here now. Attached is a spreadsheet
with test results from two platforms, a Mac laptop and a Linux server.
I used systems with high disk speed because that seemed like a worst
case for this improvement. The
On Mon, Jul 22, 2013 at 12:49 PM, Greg Stark st...@mit.edu wrote:
On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut pete...@gmx.net wrote:
I think part of the problem is that we call strcoll for each comparison,
instead of doing strxfrm once for each datum and then just strcmp for
each
Greg,
First, thanks for helping out with the CF.
* Greg Smith (g...@2ndquadrant.com) wrote:
That leaves only 1 patch where I have no idea who will commit it:
access to calls stack from GET DIAGNOSTICS statement
I'll take a look at this.
Thanks again,
Stephen
I have noticed that some people post examples using make --silent (-s).
I found this actually kind of neat to use from time to time, because
then you only see output if you have warnings or errors. But we get
some extra output that doesn't quite fit:
Writing postgres.bki
Writing schemapg.h
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Even if we thought the functionality was worth the trouble, which I
continue to doubt, this particular syntax proposal is a disaster.
Agreed. While there might be things worthwhile to add to psql's
backslash commands, this isn't one of those.
On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup prais...@redhat.com wrote:
Is pg_upgrade supposed to work even across multiple major releases? (I
know
that the README.rpm-dist is mentioning just one major release step, but it
could be bound just to actual pg_upgrade which is packaged..)
Yes
On 23 July 2013 06:10, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
I must admit to finding all of this criticism of unread code a bit
bizarre.
If you yourself are still finding bugs in the code as of this afternoon,
onlookers could be forgiven for
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
I have noticed that some people post examples using make --silent (-s).
I found this actually kind of neat to use from time to time, because
then you only see output if you have warnings or errors. But we get
some extra output that doesn't
On Thu, May 23, 2013 at 6:52 PM, Robins rob...@pobox.com wrote:
Please find attached a patch to take code-coverage of ALTER OPERATOR
FAMILY.. ADD / DROP (src/backend/commands/opclasscmds.c) from 50% to 87%.
Any and all feedback is welcome.
Committed.
--
Robert Haas
EnterpriseDB:
On Tue, Jul 23, 2013 at 09:48:16PM +0900, Michael Paquier wrote:
On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup prais...@redhat.com wrote:
Is pg_upgrade supposed to work even across multiple major releases? (I
know
that the README.rpm-dist is mentioning just one major
On Tue, Jul 23, 2013 at 12:04 AM, Greg Smith g...@2ndquadrant.com wrote:
A further look at recently ALTER OPERATOR FAMILY changes shows that Robert
has been working on those quite a bit. I'm putting him down as the
committer on this last one.
I missed that one, now committed. But just BTW,
We already do this in pg_restore by starting multiple worker processes.
Those processes should get the benefit of synchronised sequential scans.
The way the api for indexes works y wouldn't really be hard to start
multiple parallel index builds. I'm not sure how well the pg_restore thing
works
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
Writing fmgroids.h
Writing fmgrtab.c
I personally don't feel the need for those
On 7/23/13 9:06 AM, Robert Haas wrote:
But just BTW, you kind of messed up that CommitFest entry. The link you added
as a new version of the
patch was actually to a different patch from the same flock.
Fixed now, since I find myself looking back through history on
submissions often enough
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
I have noticed that some people post examples using make --silent (-s).
I found this actually kind of neat to use from time to time, because
then you only see output if you have warnings or
On Tuesday, July 23, 2013 12:27 AM Andres Freund wrote:
On 2013-07-19 10:40:01 +0530, Hari Babu wrote:
On Friday, July 19, 2013 4:11 AM Greg Smith wrote:
On 7/9/13 12:09 AM, Amit Kapila wrote:
I think the first thing to verify is whether the results posted
can be validated in some
On 2013-07-23 14:17:13 +0100, Greg Stark wrote:
We already do this in pg_restore by starting multiple worker processes.
Those processes should get the benefit of synchronised sequential scans.
The way the api for indexes works y wouldn't really be hard to start
multiple parallel index
On 2013-07-23 09:21:54 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
Writing fmgroids.h
On 2013-07-23 18:59:11 +0530, Amit Kapila wrote:
* I'd be very surprised if this doesn't make WAL replay of update heavy
workloads slower by at least factor of 2.
Yes, if you just consider the cost of replay, but it involves other
operations as well
like for standby case
(Replying on phone, please forgive bad quoting)
Isn't this pretty much what adopting ICU is supposed to give us? OS-independent
collations?
I'd be interested in seeing the rest data for this performance report, partly
as I'd like to see how ICU collations would compare when ICU is crudely
On 2013-07-23 09:27:18 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
In file included from gram.y:13612:0:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:10181:23: warning: unused variable ‘yyg’
Marc Cousin cousinm...@gmail.com writes:
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
Hm. Some experimentation shows that the plan cache is failing to switch
to a generic
This exact idea was discussed a whole back. I think it was even
implemented.
The problem Tom raised at the time is that the memory usage of the bloom
filter implies smaller or less efficient hash table. It's difficult to
determine whether you're coming out ahead or behind.
I think it should be
On Tuesday, July 23, 2013 7:06 PM Andres Freund wrote:
On 2013-07-23 18:59:11 +0530, Amit Kapila wrote:
* I'd be very surprised if this doesn't make WAL replay of update
heavy
workloads slower by at least factor of 2.
Yes, if you just consider the cost of replay, but it involves
On Tue, Jul 23, 2013 at 9:42 AM, Craig Ringer cr...@2ndquadrant.com wrote:
(Replying on phone, please forgive bad quoting)
Isn't this pretty much what adopting ICU is supposed to give us?
OS-independent collations?
Yes.
I'd be interested in seeing the rest data for this performance report,
On Tue, Jul 23, 2013 at 9:22 AM, Greg Smith g...@2ndquadrant.com wrote:
On 7/23/13 9:06 AM, Robert Haas wrote:
But just BTW, you kind of messed up that CommitFest entry. The link you
added as a new version of the
patch was actually to a different patch from the same flock.
Fixed now, since
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith g...@2ndquadrant.com wrote:
Recently I've been dismissing a lot of suggested changes to checkpoint fsync
timing without suggesting an alternative. I have a simple one in mind that
captures the biggest problem I see: that the number of backend and
On Thu, Jul 18, 2013 at 8:46 AM, Robert Haas robertmh...@gmail.com wrote:
There seems to be a consensus that we should try to get rid of
SnapshotNow entirely now that we have MVCC catalog scans, so I'm
attaching two patches that together come close to achieving that goal:
1.
On Tue, Jul 23, 2013 at 7:32 PM, Greg Stark st...@mit.edu wrote:
This exact idea was discussed a whole back. I think it was even implemented.
The problem Tom raised at the time is that the memory usage of the bloom
filter implies smaller or less efficient hash table. It's difficult to
On 07/22/2013 01:27 PM, Greg Smith wrote:
Anyone who would like to see RLS committed should consider how you can
get resources to support a skilled PostgreSQL reviewer spending time on
it. (This is a bit much to expect new reviewers to chew on usefully)
I've been working on that here, but I
On 7/23/13 10:56 AM, Robert Haas wrote:
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith g...@2ndquadrant.com wrote:
We know that a 1GB relation segment can take a really long time to write
out. That could include up to 128 changed 8K pages, and we allow all of
them to get dirty before any are
Greg,
As far as motivating new reviewers goes, let's talk about positive
feedback. Anything that complicates the release notes is a non-starter
because that resource is tightly controlled by a small number of people,
and it's trying to satisfy a lot of purposes.
Greg, you're re-arguing
On Jul 23, 2013, at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Does that create any ambiguities against formats we already support?
I'm worried about examples like this one:
select 'monday, july 22, 22:30 2013'::timestamptz;
timestamptz
2013-07-22
Andres Freund and...@2ndquadrant.com wrote:
Hm. There seems to be more things that need some more improvement
from a quick look.
First, I have my doubts of the general modus operandy of
CONCURRENTLY here. I think in many, many cases it would be faster
to simply swap in the newly built heap
Robert Haas robertmh...@gmail.com writes:
2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
to use SnapshotSelf instead. These include pgrowlocks(),
pgstat_heap(), and get_actual_variable_range().
Tom proposed that we use SnapshotDirty for this case; let me just ask
On 7/23/13 12:10 PM, Josh Berkus wrote:
Apparently it's a little much for experienced reviewers to chew on, too,
since I've been trying to get someone to review it since the beginning
of the Commitfest.
It's more than the available experienced reviewers are willing to chew
on fully as
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
to use SnapshotSelf instead. These include pgrowlocks(),
pgstat_heap(), and get_actual_variable_range().
Tom
Alvaro Herrera wrote:
Peter Eisentraut wrote:
I would suggest that these changes be undone, except that the old
SELECT FOR ... be replaced by a dynamic string that reverse-parses the
LockingClause to provide the actual clause that was used.
Here's a patch for this.
Pushed to 9.3 and
On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote amitlangot...@gmail.com wrote:
Hello,
While understanding the effect of maintenance_work_mem on time taken
by CREATE INDEX, I observed that for the values of
maintenance_work_mem less than the value for which an internal sort is
performed, the
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as get_actual_variable_range() is concerned, an MVCC snapshot
would probably be the thing to use anyway;
That surprises me, though. I really thought the point was to cost the
Greg,
It's more than the available experienced reviewers are willing to chew
on fully as volunteers. The reward for spending review time is pretty
low right now.
Short of paying for review time, I don't think we have another solution
for getting the big patches reviewed, except to rely on
On Tue, Jul 23, 2013 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as get_actual_variable_range() is concerned, an MVCC snapshot
would probably be the thing to use anyway;
Robert Haas robertmh...@gmail.com writes:
OK, so GetActiveSnapshot()?
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi.
I want add Zigzag Merge join to Index Nested Loops Join alghoritm.
http://www.cs.berkeley.edu/~fox/summaries/database/query_eval_5-8.html
Which files are responsible for Index nested loops join ? (not simple nested
loops join which has double foreach in nodeNestloop.c) nodeIndexscan.c?
Tom Lane said:
If you yourself are still finding bugs in the code as of this afternoon,
onlookers could be forgiven for doubting that the code is quite as
readable or ready to commit as all that.
Right, and we all know that all code is perfect when committed. sheesh.
(This is actually the
Andrew,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
Right, and we all know that all code is perfect when committed. sheesh.
That clearly wasn't what was claimed.
(This is actually the first time in six months that I've had occasion
to look at that part of the code; that's how long
On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote amitlangot...@gmail.com wrote:
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote amitlangot...@gmail.com wrote:
Hello,
While understanding the effect of maintenance_work_mem on time taken
by CREATE INDEX, I observed that for the values of
On Tue, Jul 23, 2013 at 9:27 PM, Stephen Frost sfr...@snowman.net wrote:
Fine- I'd have been as happy leaving this be and letting Greg commit it,
but if you'd really like to hear my concerns, I'd start with pointing
out that it's pretty horrid to have to copy every record around like
this and
* Greg Stark (st...@mit.edu) wrote:
So given that WITH ORDINALITY is really only useful for UNNEST and we
can generalize it to all SRFs on the basis that Postgres SRFs do
produce ordered sets not unordered relations it isn't crazy for the
work to be in the Function node.
I agree, it isn't
Everything was already *not* hunky-dory as soon as you did that, since
a SIGHUP would have had the same problem.
I'd be inclined to think that ALTER SYSTEM SET should not be allowed to
modify any PGC_POSTMASTER parameters.
That makes alter system set a bunch less useful, but might be
On Tue, Jul 23, 2013 at 05:23:17PM -0400, Stephen Frost wrote:
* Greg Stark (st...@mit.edu) wrote:
So given that WITH ORDINALITY is really only useful for UNNEST and we
can generalize it to all SRFs on the basis that Postgres SRFs do
produce ordered sets not unordered relations it isn't
David
On Tuesday, July 23, 2013, David Fetter wrote:
There are a lot of ways foreign tables don't yet act like local ones.
Much as I'm a booster for fixing that problem, I'm thinking
improvements in this direction are for a separate patch.
This isn't about making FDWs more like local
On Tue, Jul 23, 2013 at 06:09:20PM -0400, Stephen Frost wrote:
David
On Tuesday, July 23, 2013, David Fetter wrote:
There are a lot of ways foreign tables don't yet act like local
ones. Much as I'm a booster for fixing that problem, I'm thinking
improvements in this direction are for
On 7/23/13 2:30 PM, Josh Berkus wrote:
You know as well as me that, as consultants, we can get clients to pay for 10%
extra time
for review in the course of developing a feature
Before this number gets quoted anywhere, I think it's on the low side.
I've spent a good bit of time measuring
On 07/23/2013 03:34 PM, Greg Smith wrote:
I happen to think the review structure is one of the most important
components to PostgreSQL release quality. It used to be a single level
review with just the committers, now it's a two level structure. The
reason the Postgres code is so good isn't
I wrote:
Marc Cousin cousinm...@gmail.com writes:
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
Hm. Some experimentation shows that the plan cache is failing to switch
As failures to use a generic plan goes, that one's fairly tame. I've
seen much worse. For example:
PREPARE foo(integer[]) AS SELECT * FROM complexview WHERE id = ANY ($1);
where the caller typically supplies 1-5 array elements (or any number
less than 10, because generic parameter arrays are
On Tuesday, July 23, 2013, David Fetter wrote:
Are you saying that there's stuff that if I don't put it in now will
impede our ability to add this to FTs later?
I'm saying that it'd be a completely different implementation and that this
one would get in the way and essentially have to be
Stephen Frost said:
[stuff about foreign tables]
I think the issue with foreign tables is probably moot because if you
_did_ want to have some types of foreign tables with a fixed
ordinality, you'd probably also want qual pushdown to work for it
(i.e. so that WHERE rownum=123 doesn't have to
On 07/23/2013 09:42 PM, Craig Ringer wrote:
(Replying on phone, please forgive bad quoting)
Isn't this pretty much what adopting ICU is supposed to give us? OS-independent
collations?
Yes, we need OS-independent collations.
I'd be interested in seeing the rest data for this performance
Stephen Frost sfr...@snowman.net writes:
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
If you have legitimate technical concerns then let's hear them, now.
Fine- I'd have been as happy leaving this be and letting Greg commit it,
but if you'd really like to hear my concerns, I'd start
On Mon, Jul 22, 2013 at 10:02:30PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote:
Hmm ... good point. The other plan I'd been considering was to add
explicit tracking inside spi.c of all tuple tables created within the
On Tue, Jul 23, 2013 at 01:21:52AM +, Andrew Gierth wrote:
For hypothetical set functions we add a special case, aggordnargs=-1,
for which both the aggregate and the finalfn must be defined as
(variadic any) and parse analysis detects this case and unifies the
types of the normal args with
On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote amitlangot...@gmail.com wrote:
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote amitlangot...@gmail.com
wrote:
Hello,
While understanding the effect of maintenance_work_mem on
On Wed, Jul 24, 2013 at 11:30 AM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes jeff.ja...@gmail.com wrote:
If you are using trace_sort to report that, it reports the switch as
happening as soon as it runs out of memory.
At point, all we have been
On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote:
I haven't given this a lot of thought, but it struck me that when
rebuilding tables (be it for a restore process, or some other operational
activity) - there is more often than not a need to build an index or two,
sometimes many
[ sorry for slow response, this month has been mostly crazy ]
Antonin Houska antonin.hou...@gmail.com writes:
As far as I understand, deconstruct_recurse() ensures that
SpecialJoinInfo of a new join always gets added to higher position in
join_info_list than SJ infos of all joins located
Noah Misch said:
Other aggregates based on this syntax might not desire such type unification.
Then there would have to be some way to distinguish that. Maybe those could
have -1 and the standard hypothetical set functions -2, with some flag in
CREATE AGGREGATE to sort it out.
Having parse
On Tuesday, July 23, 2013 5:06 AM Josh Berkus wrote:
All,
Christophe just discovered something with include files which is going
to cause issues with ALTER SYSTEM SET.
So, take as a hypothetical that you use the default postgresql.conf
file, which sets shared_buffers = 32MB.
Instead of
On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote amitlangot...@gmail.com wrote:
Hello,
While understanding the effect of maintenance_work_mem on time taken
by CREATE INDEX, I observed that for the values of
85 matches
Mail list logo
