Hello list,
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
Emails in this mailing lists archive seem to indicate that
1.0 vs 3.0 - 4.0 are appropriate values on modern hardware.
Which surprised me a bit as I had thought
On 03.12.2011 01:05, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Hmm, so you're saying that the FDW function needs to be able to return
multiple paths for a single joinrel. Fair enough, and that's not
specific to remote joins. Even a single-table foreign scan
On Jan4, 2012, at 21:27 , Robert Haas wrote:
I think the first thing we need to look at is increasing the number of
CLOG buffers.
What became of the idea to treat the stable (i.e. earlier than the oldest
active xid) and the unstable (i.e. the rest) parts of the CLOG differently.
On 64-bit
On Thu, Dec 29, 2011 at 4:02 PM, Peter Eisentraut pete...@gmx.net wrote:
Is there a secret reason why
ALTER DOMAIN foo DROP CONSTRAINT nonexistent;
doesn't report any error?
If not, I think we should add one and also add the usual IF EXISTS
option.
+1.
--
Robert Haas
EnterpriseDB:
My laptop ran out of battery and turned itself off while I was just
starting up postmaster. After plugging in the charger and rebooting, I
got the following error when I tried to restart PostgreSQL:
FATAL: bogus data in lock file postmaster.pid:
postmaster.pid file was present in the data
On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
My laptop ran out of battery and turned itself off while I was just starting
up postmaster. After plugging in the charger and rebooting, I got the
following error when I tried to restart PostgreSQL:
On Thu, Jan 5, 2012 at 5:15 AM, Florian Pflug f...@phlo.org wrote:
On Jan4, 2012, at 21:27 , Robert Haas wrote:
I think the first thing we need to look at is increasing the number of
CLOG buffers.
What became of the idea to treat the stable (i.e. earlier than the oldest
active xid) and the
On Tue, Jan 3, 2012 at 2:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another thought is that it should always be safe to reuse an old
snapshot if no transactions have committed or aborted since it was
taken
Yeah, that might work better. And it'd be a win for all MVCC snaps,
not just the ones
* Robert Haas:
and (c) architectures (like 32-bit x86) where ordinary 64-bit
operations aren't atomic but special instructions (cmpxchg8b) can be
used to get that behavior.
FILD and FIST are atomic, too, and are supported by more
micro-architectures.
--
Florian Weimer
On Thu, Jan 5, 2012 at 6:15 AM, Florian Pflug f...@phlo.org wrote:
On 64-bit machines at least, we could simply mmap() the stable parts of the
CLOG into the backend address space, and access it without any locking at all.
True. I think this could be done, but it would take some fairly
careful
On Thu, Jan 5, 2012 at 8:23 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 5, 2012 at 14:18, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
My laptop ran out of battery and turned itself off while I was just starting
up postmaster. After plugging in the charger and
On Thu, Jan 5, 2012 at 5:04 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
We are experiencing a big performance regression in some queries.
In those cases the planner seems to choose a nested loop index
scan instead of hashing the index once and then joining.
I think you probably
On 05/01/12 10:04, Benedikt Grundmann wrote:
As a counter measure we are experimenting with
enable_nestloop = off
random_page_cost = 20 (instead of the previous 4).
For what it is worth we had to revert the enable_nestloop = off
change. It just moved the pain around by making other
On Thu, Jan 5, 2012 at 9:01 AM, Florian Weimer fwei...@bfk.de wrote:
* Robert Haas:
and (c) architectures (like 32-bit x86) where ordinary 64-bit
operations aren't atomic but special instructions (cmpxchg8b) can be
used to get that behavior.
FILD and FIST are atomic, too, and are supported
On 01/04/2012 08:32 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Tom said:
2. A slightly cleaner fix for this should be to duplicate the SV and
then release the copy around the SvPVutf8 call, only if it's readonly.
Fixing it in do_util_elog is entirely the wrong thing.
How
On 01/04/2012 06:20 PM, Tom Lane wrote:
Could we detect an appropriate line ending in ahwrite() after it's been
decompressed and buffer partial lines accordingly?
Not easily: there could be newlines embedded in data strings or SQL
identifiers.
Should we look at eliminating those
For what's worth here are the numbers on one of our biggest databases
(same system as I posted about separately wrt seq_scan_cost vs
random_page_cost).
0053 1001
00BA 1009
0055 1001
00B9 1020
0054 983
00BB 1010
0056 1001
00BC 1019
0069 0
00BD 1009
006A 224
00BE 1018
006B 1009
00BF 1008
006C 1008
Benedikt Grundmann bgrundm...@janestreet.com wrote:
For what's worth here are the numbers on one of our biggest
databases (same system as I posted about separately wrt
seq_scan_cost vs random_page_cost).
That's would be a 88.4% hit rate on the summarized data.
-Kevin
--
Sent via
Hi all,
I've been working on moving an extension that allows to move the ispell
dictionaries to shared segment. It's almost complete, the last FIXME is
about copying regex_t structure (stored in AFFIX).
According to regex.h the structure is fairly complex and not exactly easy
to understand, so
On Wed, Jan 4, 2012 at 3:13 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Jan 4, 2012 at 1:31 PM, Stephen Frost sfr...@snowman.net wrote:
Simon, all,
* Simon Riggs (si...@2ndquadrant.com) wrote:
(1) report all errors on a page, including errors that don't change
PostgreSQL data. This
Andrew Dunstan and...@dunslane.net writes:
On 01/04/2012 08:32 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
How do we tell if it's readonly?
SvREADONLY(sv) macro.
but it doesn't fix the one I found which passes a typeglob to elog():
do '$foo=1; elog(NOTICE,*foo);'
Andrew Dunstan and...@dunslane.net writes:
On 01/04/2012 06:20 PM, Tom Lane wrote:
Not easily: there could be newlines embedded in data strings or SQL
identifiers.
Should we look at eliminating those newlines for the future by using
U identifiers where there are embedded newlines and
On Wed, Jan 4, 2012 at 1:35 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs wrote:
My focus was on getting something working first, then tuning. If
we're agreed that we have everything apart from the tuning then we
can proceed with tests to see which works better.
Sure.
On Tue, Dec 27, 2011 at 5:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, Dec 24, 2011 at 9:25 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Dec 22, 2011 at 4:20 PM, Robert Haas robertmh...@gmail.com wrote:
Also, if it is that, what do we do about it? I don't think any of the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
My laptop ran out of battery and turned itself off while I was just
starting up postmaster. After plugging in the charger and rebooting, I
got the following error when I tried to restart PostgreSQL:
FATAL: bogus data in lock
On Thu, Jan 5, 2012 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
It appears to me that increasing the number of CLOG buffers reduced
the severity of the latency spikes considerably. In the last 100
seconds, for example, master has several spikes in the 500-700ms
range, but with 32
Simon Riggs si...@2ndquadrant.com wrote:
Robert Haas robertmh...@gmail.com wrote:
So it seems that at least on this machine, increasing the number
of CLOG buffers both improves performance and reduces latency.
I believed before that the increase was worthwhile and now even
more so.
I have a need to send banner messages to a psql client that I can set
on the server and will be displayed on any psql client that connects
to the database. This would be mostly used as an additional indicator
to which database you are connecting, but could also be used by people
to force their
Jim Mlodgenski jimm...@gmail.com wrote:
Any feedback is welcome.
You might want to add it here to make sure it doesn't slip through the
cracks:
https://commitfest.postgresql.org/action/commitfest_view/open
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 01/05/2012 10:34 AM, Tom Lane wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Indeed. David, can you file a bug on this?
BTW, shouldn't we be making some attempt to drop the
On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Indeed. David, can you file a bug on this?
I could, but don’t know what to say, and
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Question: Is this an
David E. Wheeler da...@justatheory.com writes:
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Question: Is this an issue anywhere else in PL/Perl,
On 01/05/2012 12:28 PM, David E. Wheeler wrote:
On Jan 5, 2012, at 7:34 AM, Tom Lane wrote:
That still crashes, but doesn't if we use sv_mortalcopy unconditionally.
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would
On Jan 5, 2012, at 9:41 AM, Tom Lane wrote:
I would imagine you could reproduce it by returning the same kinds of
objects as function results, since the actual problem is in utf8 to
database-encoding conversion.
No segfault, at least, though that‚s a rather bizarre error message. AFAIK,
On Jan 5, 2012, at 9:50 AM, Andrew Dunstan wrote:
The fix that has been applied, as Tom suggested, is at the point where we
call SvPVutf8(), so that's not just for elog().
Great, thanks.
As documented, it's not a scalar, and you need to stop treating it as one. If
you want it as a scalar,
On 01/05/2012 12:41 PM, Tom Lane wrote:
Is that actually a vstring? I confess I'd never heard of the things
before this thread, but I remember reading somewhere that you need
multiple dots in a string before it's considered a vstring and not
something else.
perldoc perlvar says:
The
On 01/05/2012 12:17 PM, David E. Wheeler wrote:
On Jan 5, 2012, at 9:08 AM, Andrew Dunstan wrote:
Unconditional sv_mortalcopy sounds like the thing to do then, but a
comment would help. And if this isn't a Perl bug, I would like to
know what is.
Indeed. David, can you file a bug on this?
Andrew Dunstan and...@dunslane.net writes:
The fix that has been applied, as Tom suggested, is at the point where
we call SvPVutf8(), so that's not just for elog().
That patch looks good, but do we want to look into the other point about
error recovery? The real bottom line here is that when
On 01/05/2012 01:09 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
The fix that has been applied, as Tom suggested, is at the point where
we call SvPVutf8(), so that's not just for elog().
That patch looks good, but do we want to look into the other point about
error
On Thu, Jan 5, 2012 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
I hypothesize that there are actually two kinds of latency spikes
here. Just taking a wild guess, I wonder if the *remaining* latency
spikes are caused by the effect that you mentioned before: namely, the
need to write
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we need to at least figure out a
way to provide an escape hatch for people without much shared memory.
We could do that, perhaps, by using a formula like
On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we need to at least figure out a
way to provide an escape hatch for people
On Thu, Jan 5, 2012 at 2:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we
On Thu, Jan 5, 2012 at 1:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we need to at least figure out a
way to provide an escape hatch for people
On Thu, Jan 5, 2012 at 7:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 2:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Excerpts from Simon Riggs's message of jue ene 05 16:21:31 -0300 2012:
On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Let's commit the change to 32.
I would like to do that, but I think we need to at least figure
out a way to provide an escape
Robert Haas robertmh...@gmail.com writes:
I would like to do that, but I think we need to at least figure out a
way to provide an escape hatch for people without much shared memory.
We could do that, perhaps, by using a formula like this:
1 CLOG buffer per 128MB of shared_buffers, with a
Simon Riggs si...@2ndquadrant.com writes:
On Thu, Jan 5, 2012 at 7:26 PM, Robert Haas robertmh...@gmail.com wrote:
On the other hand, I think there's a decent argument that he should
change his opinion, because 192kB of memory is not a lot. However,
what I mostly want is something that nobody
On Thu, Jan 5, 2012 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
My laptop ran out of battery and turned itself off while I was just
starting up postmaster. After plugging in the charger and rebooting, I
got the following error
On Thu, Jan 5, 2012 at 7:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that the reason it's historically been a constant is that the
original coding took advantage of having a compile-time-constant number
of buffers --- but since we went over to the common SLRU infrastructure
for several
Simon Riggs si...@2ndquadrant.com writes:
Parameterised slru buffer sizes were proposed about for 8.3 and opposed by
you.
I guess we all reserve the right to change our minds...
When presented with new data, sure. Robert's results offer a reason to
worry about this, which we did not have
On Thu, Dec 29, 2011 at 9:03 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
3. Resolve two anticipated controversies that are, respectively,
somewhat orthogonal and completely orthogonal to the binary bloat
controversy. The first (controversy A) is that I have added a new
piece of
On Thu, Jan 5, 2012 at 2:44 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
If we go with such a formula, I think 32 MB would be a more
appropriate divisor than 128 MB. Even on very large machines where
32 CLOG buffers would be a clear win, we often can't go above 1 or 2
GB of
On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would be in favor of that, or perhaps some other formula (eg, maybe
the minimum should be less than 8 for when you've got very little shmem).
I have some results that show that, under the right set of
circumstances, 8-32 is a
On Thu, Jan 5, 2012 at 2:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 5, 2012 at 2:44 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
If we go with such a formula, I think 32 MB would be a more
appropriate divisor than 128 MB. Even on very large machines where
32 CLOG
On Jan 5, 2012, at 9:55 AM, Andrew Dunstan wrote:
perldoc perlvar says:
The revision, version, and subversion of the Perl interpreter,
represented as a version object.
This variable first appeared in perl 5.6.0; earlier versions of perl
will see an undefined value. Before perl
On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
Work around perl bug in SvPVutf8().
Certain things like typeglobs or readonly things like $^V cause
perl's SvPVutf8() to die nastily and crash the backend. To avoid
that bug we make a copy of the object, which will subsequently be
garbage
On 01/03/2012 06:22 PM, Jim Nasby wrote:
On Jan 3, 2012, at 11:15 AM, Robert Haas wrote:
I think that our current freelist is practically useless, because it
is almost always empty, and the cases where it's not empty (startup,
and after a table or database drop) are so narrow that we don't
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 5, 2012 at 17:13, Tom Lane t...@sss.pgh.pa.us wrote:
I think link(2) would create race conditions of its own. I'd be
inclined to suggest that maybe we should just special-case a zero length
postmaster.pid file as meaning okay to proceed.
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 29, 2011 at 9:03 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
The first (controversy A) is that I have added a new
piece of infrastructure, pg_always_inline, which, as the name
suggests, is a portable way of insisting that a function
Excerpts from Andrew Dunstan's message of jue ene 05 19:06:54 -0300 2012:
On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
Work around perl bug in SvPVutf8().
Certain things like typeglobs or readonly things like $^V cause
perl's SvPVutf8() to die nastily and crash the backend. To avoid
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 5, 2012 at 2:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I would be in favor of that, or perhaps some other formula (eg, maybe
the minimum should be less than 8 for when you've got very little shmem).
I have some results that show that,
On 01/05/2012 05:30 PM, Alvaro Herrera wrote:
Excerpts from Andrew Dunstan's message of jue ene 05 19:06:54 -0300 2012:
On 01/05/2012 12:05 PM, Andrew Dunstan wrote:
Work around perl bug in SvPVutf8().
Certain things like typeglobs or readonly things like $^V cause
perl's SvPVutf8() to die
On 2012-01-05 10:04, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
It'd be really nice if the DBMS measured actual experienced values..
--
Jeremy
--
Sent via pgsql-hackers mailing list
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstan and...@dunslane.net wrote:
Fix breakage from earlier plperl fix.
Apparently the perl garbage collector was a bit too eager, so here
we control when the new SV is garbage collected.
I know im a little late to the party...
I can't help but think
On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstanand...@dunslane.net wrote:
Fix breakage from earlier plperl fix.
Apparently the perl garbage collector was a bit too eager, so here
we control when the new SV is garbage collected.
I know im a little
On 5 January 2012 22:27, Tom Lane t...@sss.pgh.pa.us wrote:
There is no compiler anywhere that implements always inline, unless
you are talking about a macro. inline is a hint and nothing more,
and if you think you can force it you are mistaken. So this controversy
is easily resolved: we do
I wrote:
Not easily: there could be newlines embedded in data strings or SQL
identifiers. I'm not seeing any way around this except to restore the
minimal lexing capability. One thing we could probably do is to
restrict it to be used only when reading table data, and continue to
assume that
On 1/5/12 3:00 PM, Jeremy Harris wrote:
On 2012-01-05 10:04, Benedikt Grundmann wrote:
I have a question of how to benchmark hardware to determine
the appropriate ratio of seq_page_cost vs random_page_cost.
It'd be really nice if the DBMS measured actual experienced values..
Certainly
Lately I have noticed buildfarm member jaguar occasionally failing
regression tests with
ERROR: invalid memory alloc request size 1073741824
during a VACUUM, as for example at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguardt=2012-01-04%2023%3A05%3A02
Naturally I supposed it to be
* Simon Riggs (si...@2ndquadrant.com) wrote:
I discover that non-all-zeroes holes are fairly common, just not very
frequent.
Curious, might be interesting to find out why.
That may or may not be a problem, but not something to be dealt with
here and now.
But I agree that it's not the job
On Thu, Jan 5, 2012 at 16:59, Andrew Dunstan and...@dunslane.net wrote:
On 01/05/2012 06:31 PM, Alex Hunsaker wrote:
On Thu, Jan 5, 2012 at 16:02, Andrew Dunstanand...@dunslane.net wrote:
Fix breakage from earlier plperl fix.
I can't help but think this seems a bit inefficient
So, yes,
74 matches
Mail list logo
