2009/9/30 Pavel Stehule pavel.steh...@gmail.com:
So I dropped variadic functions from mixed/named notation and little
bit modified documentation. Please, can some native English speaker
look on documentation?
Hi Pavel,
I've had a look through the documentation and cleaned up a few things.
I
Peter Eisentraut wrote:
On Fri, 2009-07-17 at 13:58 +0100, Richard Huxton wrote:
2. Titles on navigation links.
Run ./STYLING/title_links.pl and it should add title attributes to the
navigation links. This means hovering over the top links gives the title
of the page they will go to.
David E. Wheeler wrote:
On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:
For the browser, does the following match what you're after, Andrew?
- clicking chapter title opens the browser panel
- panel stays open until you click close icon
- panel contains collapsable tree of chapter/section
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
(Note that you would still need a non-default setting of
listen_addresses for -h machine_name to actually work.)
Which makes this proposal kind of
At 2009-09-30 22:08:12 -0400, t...@sss.pgh.pa.us wrote:
# local connections via TCP/IP:
hostall all samehost @authmethod@
I think that's an excellent idea.
On the other hand, I tend to be slightly against the idea of changing
the default listen_addresses from
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use. The problem this addresses is that sometimes
one needs to set work_mem fairly high to get good query plans for large joins.
However, some complex queries will then use huge amounts of memory
+ /*
+* If our initial RunningXactData had an overflowed snapshot then we
+* knew we were missing some subxids from our snapshot. We can use
+* this data as an initial snapshot, but we cannot yet mark it valid.
+* We know that the missing subxids are equal to or earlier than
+
On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Magnus Hagander mag...@hagander.net wrote:
I can certainly review the win32 encoding patch, but I was rather
hoping for some comments from others on if we're interested in a win32
only solution, or if we
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to me the only reason it exists is to force
me to change 'localhost' to '*' after installing, something i always
do almost automaticaly =)
Try
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
qualified to review them. (I don't actually think we have anybody
except Michael who's really familiar with ecpg.)
I'm afraid I'm simply not able to spend much time on this in the near future as
I'm simply too busy atm. I spend some
Stephen Frost wrote:
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to me the only reason it exists is to force
me to change 'localhost' to '*' after installing, something i always
do almost
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So here's the patch.
I don't think there is documentation required;
correct me if I am
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So
Dave Page wrote:
On Thu, Oct 1, 2009 at 1:53 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
I'd prefer to have an example as a contrib module, as well as
Michael Meskes írta:
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote:
qualified to review them. (I don't actually think we have anybody
except Michael who's really familiar with ecpg.)
I'm afraid I'm simply not able to spend much time on this in the near future
as
I'm
Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
You're probably not suggesting this, but I would be against a default
setting of 'samehost' used with 'trust'.
Essentially that would be the
Tom Lane wrote:
Having looked at the code, I think that samehost is pretty safe. I'm
still worried about samenet picking up a bogusly broad netmask --- but
samehost hard-wires the netmask at all-ones. Even if your network
configuration is really screwed up, the kernel isn't going to send
On Thu, Oct 1, 2009 at 15:26, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to use it, or that it's even there without at
least a note in the docs
On Wed, 2009-09-30 at 18:45 +0300, Heikki Linnakangas wrote:
Regarding this in InitStandbyDelayTimers:
+ /*
+* If replication delay is enormously huge, just treat that as
+* zero and work up from there. This prevents us from acting
+* foolishly when replaying old log files.
+
On Thu, Oct 01, 2009 at 03:54:37PM +0200, Magnus Hagander wrote:
On Thu, Oct 1, 2009 at 15:26, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Andrew Dunstan wrote:
So here's the patch.
I don't think there is documentation required;
correct me if I am wrong.
How will people know how to
* Albe Laurenz laurenz.a...@wien.gv.at [091001 08:54]:
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module would not hurt.
So here's the patch.
I
2009/10/1 Brendan Jurd dire...@gmail.com:
2009/9/30 Pavel Stehule pavel.steh...@gmail.com:
So I dropped variadic functions from mixed/named notation and little
bit modified documentation. Please, can some native English speaker
look on documentation?
Hi Pavel,
I've had a look through the
On Sun, 2009-09-27 at 15:35 +0300, Heikki Linnakangas wrote:
TransactionIdIsInProgress() doesn't consult the known-assigned-xids
structure. That's a problem: in the standby, TransactionIdIsInProgress()
can return false for a transaction that is still running in the master.
HeapTupleSatisfies*
Jaime Casanova jcasa...@systemguards.com.ec wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Although come to think of it ... is there any reason besides sheer
conservatism to not make the default listen_addresses value '*'?
just my 2 cents. but i always wondered about the existence of
On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
Why wouldn't the entire TOC be in a collapsed list?
Permanently on-screen? My only concern there would be for people
viewing
on phones etc.
I have to admit that I'm never looking at the Pg docs on my iPhone.
This is mainly because I use
David E. Wheeler wrote:
On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
Why wouldn't the entire TOC be in a collapsed list?
Permanently on-screen? My only concern there would be for people viewing
on phones etc.
I have to admit that I'm never looking at the Pg docs on my iPhone. This
On 10/01/2009 10:24 AM, Kevin Grittner wrote:
Trust authentication has a few valid use cases, but it does tend to
worry me that people may leave it enabled in inappropriate situations
on production clusters. I don't see how we could get rid of it, but
I'd be OK with a warning in the log when a
On Thu, 2009-10-01 at 14:29 +0300, Heikki Linnakangas wrote:
+ /*
+* If our initial RunningXactData had an overflowed snapshot then we
+* knew we were missing some subxids from our snapshot. We can use
+* this data as an initial snapshot, but we cannot yet mark it valid.
+*
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use.
Use ulimit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, 2009-09-30 at 09:33 +0300, Heikki Linnakangas wrote:
Looking at the changes to StartupMultiXact, you're changing the locking
so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
are acquire first before changing anything. Why? Looking at the other
functions in that
On Thu, Oct 1, 2009 at 10:24 AM, David E. Wheeler da...@kineticode.com wrote:
On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
Why wouldn't the entire TOC be in a collapsed list?
Permanently on-screen? My only concern there would be for people viewing
on phones etc.
I have to admit that
daveg wrote:
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use. The problem this addresses is that sometimes
one needs to set work_mem fairly high to get good query plans for large joins.
However, some complex queries will then use huge
Boszormenyi Zoltan escribió:
First, Tom Lane suggested to unify core and ecpg FETCH
syntaxes so both will accept optional FROM/IN, which I did.
SQLDA support adds new FETCH forms (Informix-specific
ones) so naturally these patches clash. There's no simple way
to make they separately
I'm looking why cometh_month fails and it is problem with last hstore
putback:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2009-09-30%2021:06:00
Stack trace is following:
6f013828 hstore_hash (7fffa050, 1395298, 1, 41,
7370616365414143, 0) + c0
Aidan Van Dyk wrote:
Can we have the check password hook function called in both the
plaintext/encrypted case, with a flag as to whether it's encrypted or
not?
It will be called in both cases, and I figured that you can
check yourself the same way that PostgreSQL does:
If isMD5(password), then
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the source code.
That's one of the things that makes them low overhead ;-)
I agree with the
On Sep 30, 2009, at 5:13 PM, Kevin Grittner wrote:
decibel deci...@decibel.org wrote:
*any* step that improves dealing with table bloat is extremely
welcome, as right now you're basically stuck rebuilding the table.
+1
Although, possibly more irritating than actually rebuilding it is
Stef Walter stef-l...@memberwebs.com writes:
Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
You're probably not suggesting this, but I would be against a default
setting of 'samehost'
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use.
Use ulimit.
What about plataforms (Windows) that don't have ulimit?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
On Thu, Oct 1, 2009 at 11:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Stef Walter stef-l...@memberwebs.com writes:
Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
You're probably not
Euler Taveira de Oliveira eu...@timbira.com writes:
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use.
Use ulimit.
What about plataforms (Windows) that don't have ulimit?
Get a real
of view if it doesn't work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
hs-riggs-branch-20091001.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Simon Riggs wrote:
Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
while assuming it is calculated the new way. The new way is just to grab
nextXid since we have XidGenLock and do TransactionIdRetreat() on it.
Ok, good, that's what I thought too. I'll fix that.
--
In response to Euler Taveira de Oliveira eu...@timbira.com:
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a
backend
can allocate for its own use.
Use ulimit.
What about plataforms (Windows) that don't have
On Thu, Oct 1, 2009 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Euler Taveira de Oliveira eu...@timbira.com writes:
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a
backend
can allocate for its own use.
Use ulimit.
decibel wrote:
So while something that makes it easier to clean out the end of a
table would be good, I think the critical need is a way to make
vacuum more aggressive about obtaining the exclusive lock.
I wonder if we should have a different mode of operation that only
attempted the truncate
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if we should have a different mode of operation that only
attempted the truncate (say VACUUM TRUNCATE), optionally being
non-conditional about obtaining the required lock. That said, I wonder
even more whether any such hacks are still
On Thu, 2009-10-01 at 18:47 +0300, Heikki Linnakangas wrote:
Could you look into these two TODO items you listed on the wiki page:
Unless we agree otherwise, if its listed on the Wiki page then I will
work on it.
Maybe not as when you might like it, but I am working through the list.
5 new
On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
You're not being fair with me. The dependencies are quite
technical.
I'm sorry that you interpreted my email this way, it wasn't at all meant to
offend you.
First, Tom Lane suggested to unify core and ecpg FETCH
syntaxes so
On Thu, 2009-10-01 at 18:48 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
while assuming it is calculated the new way. The new way is just to grab
nextXid since we have XidGenLock and do TransactionIdRetreat() on
Robert Haas robertmh...@gmail.com writes:
What WOULD be useful is to find a way to provide a way to configure
work_mem per backend rather than per executor node. But that's a much
harder problem.
I think it's mostly a planner problem: how do you deal with the fact
that that would make cost
Robert Haas escreveu:
On Thu, Oct 1, 2009 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Euler Taveira de Oliveira eu...@timbira.com writes:
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a
backend
can allocate for its
On Thu, 2009-10-01 at 12:05 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I wonder if we should have a different mode of operation that only
attempted the truncate (say VACUUM TRUNCATE), optionally being
non-conditional about obtaining the required lock. That
Zdenek Kotala zdenek.kot...@sun.com writes:
I'm looking why cometh_month fails and it is problem with last hstore
putback:
I think this is the same 64-bit problem we fixed last night --- wait for
the next rebuild before worrying.
regards, tom lane
--
Sent via
Simon Riggs si...@2ndquadrant.com writes:
No real need to be random is there? In the bloated space scenario,
VACUUM will be triggered but will be unable to remove the empty blocks.
So in that case VACUUM can hint the FSM to perform start from beginning
of relation behaviour.
No, that's an
Simon Riggs si...@2ndquadrant.com wrote:
It would be more useful to think of this as look for huge chunks of
space and fill them rather than start at beginning, since space
won't always be right at start.
Either I misunderstand you or I disagree. If there's a huge chunk of
space near the
Euler Taveira de Oliveira eu...@timbira.com writes:
I see. Tough problem is: how do we get per backend memory usage accurately? Is
it relying on OS specific API the only way?
Given all the third-party libraries (perl, python, libxml2, yadda yadda)
that can be in use and won't go through palloc,
On Thu, 2009-10-01 at 11:32 -0500, Kevin Grittner wrote:
Either I misunderstand you or I disagree.
That does seem to be a common stance, though I will read on. :-)
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, 2009-10-01 at 11:32 -0500, Kevin Grittner wrote:
If there's a huge chunk of
space near the end, and many many smaller spaces spread throughout,
what I'd like is for rows to be placed in those small ones. This
would minimize the number of pages to read for queries, and would
present
Tom Lane escreveu:
Robert Haas robertmh...@gmail.com writes:
What WOULD be useful is to find a way to provide a way to configure
work_mem per backend rather than per executor node. But that's a much
harder problem.
I think it's mostly a planner problem: how do you deal with the fact
that
Simon Riggs si...@2ndquadrant.com writes:
Yes, as Tom points out, this must be done with bias away from the very
end of the table.
I meant that we should start from the beginning of large spaces and that
we shouldn't assume that all space worth filling is at start of
relation.
Right. One
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the source code.
That's one
Magnus Hagander escreveu:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
How will people know how to use it, or that it's even there without at
least a note in the docs somewhere?
We don't normally document function hooks anywhere but the
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's going to link to
external code like cracklib, it probably is
Alvaro Herrera alvhe...@commandprompt.com writes:
Oh, BTW, did anyone get interested in adding the bits to disable the OOM
killer for postmaster on the various Linux initscripts? It needs some
games with /proc/pid/oom_adj and requires root privileges, but I think
an initscript is in an
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I was imagining that this would be something for individual distros
to tackle. It's probably not portable enough to go into the
contrib/start-scripts examples. On the other hand, it'd make lots
of sense to have the Fedora or Debian or whatever scripts
On Thu, Oct 1, 2009 at 19:07, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's
On Thu, Oct 01, 2009 at 01:07:04PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Oh, BTW, did anyone get interested in adding the bits to disable the OOM
killer for postmaster on the various Linux initscripts? It needs some
games with /proc/pid/oom_adj and requires root privileges, but I think
an
Michael Meskes írta:
On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote:
You're not being fair with me. The dependencies are quite
technical.
I'm sorry that you interpreted my email this way, it wasn't at all meant to
offend you.
Please, accept my apologies, I
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Oct 1, 2009 at 17:24, Tom Lane t...@sss.pgh.pa.us wrote:
I agree with the subsequent comments suggesting a sample module that
actually does something useful --- although if it's going to link to
external code like
Petr Jelinek pjmo...@pjmodos.net writes:
because it seems like merging privileges seems to be acceptable for most
(although I am not sure I like it, but I don't have better solution for
managing conflicts), I changed the patch to do just that.
It's not clear to me whether we have consensus
Stephen Frost sfr...@snowman.net writes:
I'm not exactly keen on Debian init scripts hacking kernel settings.
Should it hack up the shared memory numbers too? This is not what I
would consider 'init script' material for specific applications.
What was suggested was tweaking the oom_adj
Magnus Hagander mag...@hagander.net writes:
That said, it would still be good to have something actually *useful*
in contrib. A bit more than just comparing userid and password.
Perhaps at least being able to set the min length, and the requirement
on having 1 character class?
+1. There's
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
because it seems like merging privileges seems to be acceptable for most
(although I am not sure I like it, but I don't have better solution for
managing conflicts), I changed the patch to do just that.
Stephen Frost sfr...@snowman.net writes:
This doesn't actually address the entire problem. How about
schema-level default grants which you want to override with per-role
default grants? Or the other way around? Is it always only more
permissive with more defaults? Even when the grantee is
Tom Lane wrote:
Stef Walter stef-l...@memberwebs.com writes:
Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
You're probably not suggesting this, but I would be against a default
setting
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
Please, accept my apologies, I only tried to express my
frustration, this is not a good situation for either of us.
Apologies accepted, email is a difficult means of communication anyway. It
leads to misunderstanding IMO.
You
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
This doesn't actually address the entire problem. How about
schema-level default grants which you want to override with per-role
default grants? Or the other way around? Is it always only more
permissive
Stephen Frost sfr...@snowman.net writes:
Erm, wait, we're going to drop the only piece of this that outside folks
have actually been asking for? Specifically, having per-schema default
ACLs?
They are per-schema for the objects belonging to the granting user.
Otherwise you have a bunch of
Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
Erm, wait, we're going to drop the only piece of this that outside folks
have actually been asking for? Specifically, having per-schema default
ACLs?
They are per-schema for the objects belonging to the granting user.
Otherwise
Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Yes, as Tom points out, this must be done with bias away from the
very end of the table.
I meant that we should start from the beginning of large spaces and
that we shouldn't assume that all space worth filling is
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
So for example we might try resetting the search to the start of the
relation with probability 0.01.
If I understand the heuristic you propose, and my math skill haven't
eroded too badly from lack of use,
Michael Meskes írta:
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
Please, accept my apologies, I only tried to express my
frustration, this is not a good situation for either of us.
Apologies accepted, email is a difficult means of communication anyway. It
Peter Eisentraut wrote:
I'm not exactly sure what the goal is, however. You built the
documentation at some point. Then it gets updated when necessary. You
can delete the documentation by running make -C doc maintainer-clean.
Then it's gone forever and never reappears unless you explicitly
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Yes, as Tom points out, this must be done with bias away from the
very end of the table.
I meant that we should start from the beginning of large spaces and
that we shouldn't assume that all
On Thu, Oct 01, 2009 at 10:35:55AM -0400, Tom Lane wrote:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a backend
can allocate for its own use.
Use ulimit.
That was my initial thought too. However, ulimit() is documented as superceded
by
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
So for example we might try resetting the search to the start of
the
relation with probability 0.01.
If I understand the heuristic you propose, and my math skill
On Thu, Oct 01, 2009 at 11:47:43AM -0400, Tom Lane wrote:
Euler Taveira de Oliveira eu...@timbira.com writes:
Tom Lane escreveu:
daveg da...@sonic.net writes:
I'd like to propose adding a new GUC to limit the amount of memory a
backend
can allocate for its own use.
Use ulimit.
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
0.99 percent chance to continue the sweep
Make that a 99% chance, or a 0.99 chance (in case the typo was not
apparent).
Am I saying something stupid here?
Well, besides that line?
-Kevin
--
Sent via pgsql-hackers mailing list
On Thu, Oct 1, 2009 at 3:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We probably could do with more bias. For example, we still prefer pages
close to the page we last inserted to, by searching for free space in
the same FSM page first, before starting the search from
Kevin Grittner kevin.gritt...@wicourts.gov writes:
The way I figure it, if there is a 0.01 chance to reset the sweep,
then there's a 0.99 percent chance to continue the sweep from the last
position. 0.99^229 is about 0.1, which means there is a 10% chance
not to have reset after that many
--On 30. September 2009 13:19:53 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, the patch is now
split across three separate emails. :-(
That's correct, here it
Robert Haas robertmh...@gmail.com writes:
The elephant in the room here is that if the relation is a million
pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
is going to help us truncate the relation unless every tuple on page
1,000,000 gets updated or deleted.
Well, there
On Thu, Oct 1, 2009 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A possible downside of keeping things compact this way is that you'd
probably get a longer average search distance because of all the early
pages tending to remain full. Maybe what we want is some bias against
inserting in the
On Thu, Oct 1, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The elephant in the room here is that if the relation is a million
pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
is going to help us truncate the relation unless
Bernd Helmle escribió:
--On 30. September 2009 13:19:53 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, the patch is now
split across three separate emails. :-(
Robert Haas robertmh...@gmail.com wrote:
The elephant in the room here is that if the relation is a million
pages of which 1-100,000 and 1,000,000 are in use, no amount of bias
is going to help us truncate the relation unless every tuple on page
1,000,000 gets updated or deleted.
Perhaps
Tom Lane t...@sss.pgh.pa.us writes:
That doesn't preclude also providing some more-invasive tools
that people can use when they do get into that situation;
About this side of things, what about having any query which asks for
system columns (any of them) take a specific (new) exclusive row
1 - 100 of 119 matches
Mail list logo
