On Tue, Oct 8, 2013 at 01:25:30PM +0900, KONDO Mitsumasa wrote:
> (2013/10/08 10:35), Bruce Momjian wrote:
> >docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1
> Thank you for creating good release note. I have one comment.
>
> In 9.1 and 9.2 release not
On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian wrote:
> On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
> > > I have developed the attached patch which implements an auto-tuned
> > > effective_cache_size which is 4x the size of shared buffers
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule
> > wrote:
> > >> I have developed the attached patch based on your suggestion. I did not
On Tue, Oct 8, 2013 at 06:31:03PM +0200, Pavel Stehule wrote:
>
>
>
> 2013/10/8 Bruce Momjian
>
> On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > > On Sat, Sep 1
s from the SQL file to
create the new function signature.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Tue, Oct 8, 2013 at 02:25:25PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > Do we need to update any version or anything? I didn't think so.
>
> I think there should be an 1.1 version here. That way, if somebody is
> using the existing definition
On Tue, Oct 8, 2013 at 01:04:18PM -0600, Kevin Hale Boyes wrote:
> The patch contains a small typo in config.sgml. Probably just drop the "is"
> from "is can".
>
> +results if this database cluster is can utilize most of the memory
>
> Kevin.
;Fix rare GROUP BY query error caused by improperly processed *data*
> type modifiers (Tom Lane)"
>
> Assuming the change has to do with the following commit:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bd5ab4b28745605493ab7061724ba0375ee9593a
essage-id/e1vofi4-0005nz...@wrigleys.postgresql.org
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
lts
become 10x larger.
FYI, I based maintenance_work_mem's default on shared_buffers, not on
work_mem because it was too complex to change maintenance_work_mem when
someone changes work_mem.
I will work on auto-tuning temp_buffers next. Any other suggestions?
wal_buffers is already auto-
On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > Josh Berkus suggested here that work_mem and maintenance_work_mem could
> > be auto-tuned like effective_cache_size:
> >
> > http://ww
On Wed, Oct 9, 2013 at 04:38:01PM +0200, Andres Freund wrote:
> On 2013-10-09 10:35:28 -0400, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 04:32:44PM +0200, Andres Freund wrote:
> > > On 2013-10-09 10:30:46 -0400, Bruce Momjian wrote:
> > > > Josh Berkus su
ork_mem can depend on work_mem ~ work_mem * 1 * max_connection /
> 4
That is kind of hard to do because we would have to figure out if the
old maintenance_work_mem was set from a default computation or by the
user.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Oct 9, 2013 at 10:45:52AM -0400, Bruce Momjian wrote:
> On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> > Effectively, if every session uses one full work_mem, you end up with
> > total work_mem usage equal to shared_buffers.
> >
> >
te of shared_buffers and
everything else would fall in line.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, Oct 9, 2013 at 11:06:07AM -0400, Andrew Dunstan wrote:
>
> On 10/09/2013 10:45 AM, Bruce Momjian wrote:
> >On Wed, Oct 9, 2013 at 04:40:38PM +0200, Pavel Stehule wrote:
> >> Effectively, if every session uses one full work_mem, you end up with
> >>
lse would fall in line.
>
>
> I understand, but your proposal change a logic to opposite direction. Maybe
> better is wait to new GUC parameter, and then implement this feature, so be
> logical and simply understandable.
OK, I can easily do that. What do others think?
--
Bru
On Wed, Oct 9, 2013 at 12:25:49PM -0400, Bruce Momjian wrote:
> > I'm not saying don't do it, but I think we need to be quite
> > conservative about it. A reasonable default might be (shared_buffers
> > / (n * max_connections)) FSVO n, but I'm not sure wh
On Wed, Oct 9, 2013 at 12:41:53PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I think we should try to hit the existing defaults, which would mean we
> > would use this computation:
>
> For my 2c, I was hoping this would improve things for o
g to be
worse for some users, but I believe they will be better for most users.
Having really bad defaults so everyone knows they are bad really isn't
user-friendly because the only people who know they are really bad are
the people who are tuning them already. Again, we need to think of the
t
o my points about the sorts of scenarios in which that
> might cause surprising and hard-to-debug results.
Well, pointing out that is will be negative for some users (which I
agree) doesn't refute that it will be better for most users.
--
Bruce Momjian http://momjian.us
En
On Wed, Oct 9, 2013 at 02:34:19PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 2:28 PM, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 01:49:23PM -0400, Robert Haas wrote:
> >> > Having really bad defaults so everyone knows they are bad really isn't
> >&g
(1 row)
and for shared_buffers of 2GB:
test=> show shared_buffers;
shared_buffers
----
2GB
(1 row)
test=> SHOW work_mem;
work_mem
--
6010kB
(1 row)
test=> SHOW mainte
used maint_work_mem instead of work_mem
> for bulk-loading indexes. What was the reason there?
Because 'maintenance' operations were rarer, so we figured we could use
more memory in those cases.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Oct 9, 2013 at 03:04:24PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 2:15 PM, Bruce Momjian wrote:
> > I did like Josh's idea about using autovacuum_max_workers for
> > maintenance_work_mem, though I used the shared_buffers/4 calculation.
>
> I d
On Wed, Oct 9, 2013 at 03:57:14PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 3:31 PM, Bruce Momjian wrote:
> > Splitting out vacuum_work_mem from maintenance_work_mem is a separate
> > issue. I assume they were combined because the memory used for vacuum
> > i
On Wed, Oct 9, 2013 at 08:55:33PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
> > I disagree. I think we can get a forumla that is certainly better than
> > a fixed value. I think the examples I have shown do have better value
> > than
test=> SHOW maintenance_work_mem;
maintenance_work_mem
--
699050kB
(1 row)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/con
e a parameter to initdb
which specifies how much memory you want to use, and set a new variable
available_mem from that, and have things auto-tune based on that value
in the backend.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Ev
On Wed, Oct 9, 2013 at 09:34:16PM -0400, Robert Haas wrote:
> On Wed, Oct 9, 2013 at 9:11 PM, Bruce Momjian wrote:
> > On Wed, Oct 9, 2013 at 08:55:33PM -0400, Robert Haas wrote:
> >> On Wed, Oct 9, 2013 at 4:10 PM, Bruce Momjian wrote:
> >> > I disagree. I thin
On Wed, Oct 9, 2013 at 08:15:44PM -0700, Peter Geoghegan wrote:
> On Wed, Oct 9, 2013 at 8:02 PM, Bruce Momjian wrote:
> > I think the simplest solution would be to have a parameter to initdb
> > which specifies how much memory you want to use, and set a new variable
> > av
On Thu, Oct 10, 2013 at 11:01:52PM +0900, MauMau wrote:
> From: "Bruce Momjian"
> >I will work on auto-tuning temp_buffers next. Any other suggestions?
> >wal_buffers is already auto-tuned.
>
> Great work. I'm looking forward to becoming able to fully ut
db. I do think an
available_mem parameter for initdb would help though, to be set in
postgresql.conf.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pg
n,
auto-tuning would not be affected by these changes. Calculating only
with available_mem - shared_buffers would give stability and
predicability to the auto-tuning system.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ E
On Thu, Oct 10, 2013 at 11:18:46AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, Oct 10, 2013 at 07:24:26AM -0700, Kevin Grittner wrote:
> > > Robert Haas wrote:
> > > > I actually had the thought that it might be somethin
On Thu, Oct 10, 2013 at 11:45:41AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Thu, Oct 10, 2013 at 11:18:46AM -0400, Stephen Frost wrote:
> > > For this case, I think the suggestion made by MauMau would be better-
> > > tell the u
On Thu, Oct 10, 2013 at 12:00:54PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Well, I like the idea of initdb calling the tool, though the tool then
> > would need to be in C probably as we can't require python for initdb.
> > The tool
On Thu, Oct 10, 2013 at 12:39:04PM -0400, Andrew Dunstan wrote:
>
> On 10/10/2013 12:28 PM, Bruce Momjian wrote:
> >
> >How do we handle the Python dependency, or is this all to be done in
> >some other language? I certainly am not ready to take on that job.
>
>
&
On Thu, Oct 10, 2013 at 12:59:39PM -0400, Andrew Dunstan wrote:
>
> On 10/10/2013 12:45 PM, Bruce Momjian wrote:
> >On Thu, Oct 10, 2013 at 12:39:04PM -0400, Andrew Dunstan wrote:
> >>On 10/10/2013 12:28 PM, Bruce Momjian wrote:
> >>>How do we handle the Python
On Thu, Oct 10, 2013 at 10:20:02AM -0700, Josh Berkus wrote:
> On 10/09/2013 02:15 PM, Bruce Momjian wrote:
> > and for shared_buffers of 2GB:
> >
> > test=> show shared_buffers;
> > shared_buffers
> >
> > 2GB
&g
change the multiples
> of work_mem that a connection would use?
I assume that a connection pooler would keep processes running longer,
so even if they were not all using work_mem, they would have that memory
mapped into the process, and perhaps swapped out.
--
Bruce Momjian http
8GB
(1 row)
test=> SHOW work_mem;
work_mem
--
167772kB
(1 row)
test=> SHOW maintenance_work_mem;
maintenance_work_mem
--
699050kB
(1 row)
Patch attached.
--
On Thu, Oct 10, 2013 at 02:44:12PM -0400, Peter Eisentraut wrote:
> On 10/10/13 11:31 AM, Bruce Momjian wrote:
> > Let me walk through the idea of adding an available_mem setting, that
> > Josh suggested, and which I think addresses Robert's concern about
> > larger
I specifically have it
> rotate out old connections once an hour for this reason.
Just as a point of education, this is a good idea why you want to
allocate swap even if you expect your workload to fit in memory.
Pushing unused memory to swap is a good use of swap.
--
Bruce Momjian
ting code where
effective_cache_size autotunes on shared_buffers, and we just up
work_mem's default, tell people to set shared_buffers properly, and call
it a day.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ E
f
(1 row)
then in C:
test2=> SHOW lc_collate;
lc_collate
C
(1 row)
test2=> select E'ab\n'::CHAR(10) < E'ab '::CHAR(10);
?column?
--
f
(1 row)
You c
on that will
make configuration suggestions or use ALTER SYSTEM to set values. I
could do it in PL/pgSQL, but PL/Perl would allow me to run operating
system commands to probe for OS information. The function could look at
statistics and pg_buffercache output, and would be run during a typical
worklo
On Tue, Oct 15, 2013 at 02:32:47PM +0900, KONDO Mitsumasa wrote:
> Sorry for my reply late...
>
> (2013/10/08 23:26), Bruce Momjian wrote:
> > First, I want to apologize for not completing the release notes earlier
> > so that others could review them. I started working on
On Tue, Oct 8, 2013 at 09:05:37AM -0400, Bruce Momjian wrote:
> On Tue, Oct 8, 2013 at 05:08:17PM +0530, Rushabh Lathia wrote:
> > This
> > might be a case where throwing an error is actually better than trying
> > to make sense of the input.
> >
> >
ferent results:
>
> select 'ab'::char(3) collate "en_US" < E'ab\n'::char(3) collate
> "en_US";
> ?column?
> --
> t
> (1 row)
>
> select 'ab ':
I am seeing this compiler warning in git head:
rowtypes.c: In function 'record_image_cmp':
rowtypes.c:1433: warning: 'cmpresult' may be used
uninitialized in this function rowtypes.c:1433: note: 'cmpresult' was
declared here
--
Bruce Momj
> considerations to get. So I quite agree.
Are there any optimizations we have avoided, or 'volatile' designations
added, only for Alpha? Could we improve other things if Alpha support
was dropped?
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Oct 16, 2013 at 11:49:13AM -0700, Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I am seeing this compiler warning in git head:
> >
> > rowtypes.c: In function 'record_image_cmp':
> > rowtypes.c:1433: warning: 'cmpresult'
t modern systems. That undermines
> completely my reasoning above.
>
> Given that, it probably makes sense for us to be rather more liberal
> in setting work_mem that I was suggesting.
Ah, yes, this came up last year (MMAP_THRESHOLD):
http://www.postgresql.org/message-id/2012073
On Thu, Oct 3, 2013 at 05:24:49PM -0400, Bruce Momjian wrote:
> On Thu, Oct 3, 2013 at 02:48:20PM -0400, Robert Haas wrote:
> > On Thu, Oct 3, 2013 at 2:43 PM, Heikki Linnakangas
> > wrote:
> > > It seems we've all but decided that we'll require reindexi
On Sat, Oct 19, 2013 at 05:11:55PM -0400, Bruce Momjian wrote:
> I am in Moscow with Alexander and we were discussing GIN pg_upgrade
> issues. One option we have already discussed was to take the old GIN
> index code and put it in a separate directory, and call the new GIN
> ind
Andres Freund
commit 4c641d994e19676ef2fec574d52d2156ffc2b3ce
Author: Robert Haas
Date: Thu Jun 6 10:14:46 2013 -0400
Backport log_newpage_buffer.
Andres' fix for XLOG_HEAP2_VISIBLE on unitialized pag
dramatic engineerings feats that have made us famous.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
l extent of this feature?
> >>
> > It says these enhancement on interface allows extensions to implement
> > join operation in their own way (including remote join in case of FDW),
> > however, enhancement of postgres_fdw is not yet upstreamed.
>
> Thank you for this
ound to the
> new master.
Did you read this thread convering the same topic from a few weeks ago?
http://www.postgresql.org/message-id/flat/55fa2537.4070...@gmx.net#55fa2537.4070...@gmx.net
--
Bruce Momjian http://momjian.us
EnterpriseDB htt
On Wed, Apr 29, 2015 at 03:48:04PM -0400, Bruce Momjian wrote:
> On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote:
> > > It seems to me that waiting for 9.6 for what's arguably a bug fix is too
> > > much. It's not like this is a new feature. Why don&
"pg_ctl status" or some parsing of postmaster.pid with kill(pid, 0)
> for example.
To disable the old cluster, pg_upgrade rename pg_control to
pg_control.old in disable_old_cluster(). You should do that, or
pg_upgrade should use whatever new method you choose.
--
Bruce Momjian
and resources best. I am not sure if we
have succeeded because of our current non-retain mode, or in spite of
it. It might be time to switch to a default-retain mode, especially
since most other projects have that mode, but we should be clear what we
are getting into.
--
Bruce Momjian
n the community but don't code. Bug triage is exactly the
> kind of thing very part-time community supporters can do, if we make it
> easy for them to do.
Yes. Part of the problem is that tracker maintenance is almost done in
a closet, so there is little outward reinforcement to keep peo
On Tue, Oct 6, 2015 at 03:33:20PM -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > On 10/06/2015 10:57 AM, Josh Berkus wrote:
> > >On 10/06/2015 10:17 AM, Bruce Momjian wrote:
>
> > >Speaking of which ... this project is rich in skilled users who are
>
are sync'd to the main repository from the translations
> project - so I assume this needs to be submitted there, but I don't
> know how.
I think the details are here:
https://wiki.postgresql.org/wiki/NLS
--
Bruce Momjian http://momjian.us
EnterpriseDB
Any news on this item from 2013, worked on again 2014?
---
On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
> > Attached is what I have
nd me of the limits:
-- email subject limit -----
-- gitweb summary limit --
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
I encourage others to also update the list to make it more accurate.
Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote:
> On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
>
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgr
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Probably the most controvertial change was to move on-disk bitmap
> > indexes to the "not wanted" section, though I kept the links in case we
> > change our minds. I
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have spend the past few days updating our TODO list, removing
> > completed and now-unnecessary items:
> >
> > https://wiki.postgresql.org/wiki/Todo
>
> Thanks. W
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Are you suggesting I remove those links? It is kind of odd to have
> > links to patches for features we don't want, or just keep it?
>
> No, quite the contrary -- I thi
ure we have
any mechanism now to close those parallel processes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
--
Sen
ing anyway.
>
> This looks more like a bug to me than a To-do item.
Uh, many TODO items are bugs.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscriptio
e use fork() and on Windows we use thread. It
is not clear in the TODO list which platform this is for. I don't see
any signal control in the pg_upgrade source code.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, s
his problem is not
pg_upgrade-specific as there is no signal control in pg_upgrade --- you
are just getting the defaults.
(Updated TODO to mention Linux.)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once
email list.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Fri, Oct 30, 2015 at 09:56:48AM +0100, Andres Freund wrote:
> Hi,
>
> I don't really want to discuss patent issues publically.
While we don't want to discuss patented ideas, the patent terms are an
imporant topic here.
> On 2015-10-30 04:47:35 -0400, Bruce Momjian wro
On Fri, Oct 30, 2015 at 04:47:35AM -0400, Bruce Momjian wrote:
> Therefore, I caution people from viewing the Greenplum source code as
> you might see patented ideas that could be later implemented in
> Postgres, opening Postgres up to increased patent violation problems. I
> am al
On Sun, Nov 1, 2015 at 01:27:13AM -0500, Bruce Momjian wrote:
> On Fri, Oct 30, 2015 at 04:47:35AM -0400, Bruce Momjian wrote:
> > Therefore, I caution people from viewing the Greenplum source code as
> > you might see patented ideas that could be later implemented in
> &
don't think
any of these companies would sue the community for patent infringement,
they could sue users, and the company could be bought by a sinister
company that could enforce those patents. For example, few had problems
with Sun's control over Java, but when Oracle bought Sun, more peop
people to be aware of these risks. I doubt we can
really do anymore than warn folks as there is just no good boundary on
how to avoid problems, as Andres and Simon pointed out. Josh is right
that patent problems have been a rarity, and I have every hope that this
will
d new facilities will be available to
external sharding solutions as well.
Is this acceptable?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscri
On Wed, Nov 4, 2015 at 07:58:52AM -0500, Bruce Momjian wrote:
> [BCC to pgsql-cluster-hack...@postgresql.org]
>
> I have summarized the Vienna cluster summit meeting from last week by
> adding italicized answers to the agenda questions, even though we didn't
&g
This git cartoon was too funny not to share:
http://xkcd.com/1597/
Maybe we need it on our git wiki page. ;-)
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be
"page
info map" isn't very descriptive. "page status" or "page state" might
make more sense, but even then, free space is a kind of page
status/state. What is happening is that broadening the name to cover
both visibility and freeze stat
I have applied the attached patch to git head to fix the new SQL tablespace
location function usage in pg_upgrade to properly check cluster version
numbers, and a fix missing table alias.
I found this problem during testing.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Fri, Jan 20, 2012 at 07:01:46AM +0200, Peter Eisentraut wrote:
> On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote:
> > For that reason, I wonder if I should just hard-code the plpython
> > rename into the pg_upgrade test in check_loadable_libraries().
>
> Yes, I h
ization patch ;)
I agree that COPY is ripe for optimization, and I am excited you have
some ideas on this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent vi
uld be to
zero the _hint_ bits before doing the CRC checksum. That would avoid
the problem of WAL-logging the hint bits.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent
ve you considered the CRC might match a valuid page version number?
Is that safe?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-h
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
> On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian wrote:
> > On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
> >> > Also, as far as I can see this patch usurps the page version field,
> >> >
y need to allocate
> them to this specific use ahead of time - especially since that is the
> exact decision we took last time when we reserved 16 bits for the
> version.
Right, but I am thinking we should set things up so we can grow the page
version number into the unused bit, rather than
k there is any magic bullet that will allow for page header
extension by pg_upgrade. If it is going to be done, it would have to
happen in the backend while the system is running. Anything that
requires pg_upgrade to do lots of reads or writes basically makes
pg_upgrade useless.
--
On Mon, Feb 06, 2012 at 12:59:59PM -0500, Bruce Momjian wrote:
> > > I'm also not very comfortable with the idea of having flags on the page
> > > indicating whether it has a checksum or not. It's not hard to imagine a
> > > software of firmware bug or hardw
er of these would be enough
to justify the additional 1% size, but both make it an easy decision for
me.
FYI, I believe COPY needs similar optimizations; we have gotten repeated
complaints about its performance and this method of optmization might
also be our only option.
--
Bruce Momjian
On Mon, Feb 06, 2012 at 04:19:07PM -0500, Bruce Momjian wrote:
> Peter Geoghegan obviously has done some serious work in improving
> sorting, and worked well with the community process. He has done enough
> analysis that I am hard-pressed to see how we would get similar
> improve
On Mon, Feb 06, 2012 at 10:49:10PM +, Peter Geoghegan wrote:
> On 6 February 2012 21:19, Bruce Momjian wrote:
> > Peter Geoghegan obviously has done some serious work in improving
> > sorting, and worked well with the community process.
>
> Thank you for acknowle
On Mon, Feb 06, 2012 at 06:43:04PM -0500, Bruce Momjian wrote:
> On Mon, Feb 06, 2012 at 10:49:10PM +, Peter Geoghegan wrote:
> > On 6 February 2012 21:19, Bruce Momjian wrote:
> > > Peter Geoghegan obviously has done some serious work in improving
> > > sortin
901 - 1000 of 17339 matches
Mail list logo
