On 7 May 2014 02:05, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Prior to the development cycle towards v9.5, I'd like to reopen
the discussion of custom-plan interface. Even though we had lots
of discussion during the last three commit-fests, several issues
are still under discussion. So, I'd
On Wed, May 7, 2014 at 1:21 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 05/07/2014 07:16 AM, Michael Paquier wrote:
On Wed, May 7, 2014 at 8:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
FWIW, the format you're using makes applying
On 7 May 2014 02:05, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Prior to the development cycle towards v9.5, I'd like to reopen the
discussion of custom-plan interface. Even though we had lots of
discussion during the last three commit-fests, several issues are
still under discussion. So,
On 6 May 2014 17:55, Andres Freund and...@2ndquadrant.com wrote:
All this changes is the cost of
IndexScans that would use more than 25% of shared_buffers worth of
data. Hopefully not many of those in your workload. Changing the cost
doesn't necessarily prevent index scans either. And if
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure.
16396 is a gin index.
If I have it ignore checksum failures, there is no apparent misbehavior.
I'm trying to bisect it, but it could
Hi,
On 2014-05-07 00:35:35 -0700, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure.
16396 is a gin index.
Over which type? What was the load? make check?
If I
On Tue, May 6, 2014 at 7:04 PM, Christoph Berg c...@df7cb.de wrote:
Hi,
if you split configuration and data by setting data_directory,
postgresql.auto.conf is writen to the data directory
(/var/lib/postgresql/9.4/main in Debian), but tried to be read from
the etc directory
On 7 May 2014 08:17, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Let me clarify. This mechanism allows to add alternative scan/join paths
including built-in ones, not only custom enhanced plan/exec node, isn't it?
Probably, it is a variation of above proposition if we install a handler
function
On 05/06/2014 11:30 PM, Peter Geoghegan wrote:
On Tue, May 6, 2014 at 12:48 PM, Andres Freund and...@anarazel.de wrote:
Enthusiatically seconded. I've asked for that about three times without much
success. If it had been my decision the patch wouldn't have been merged without
that and other
Hi all
As part of development on BDR the issue of GUC globals not being
PGDLLEXPORT'ed has been run into a few times.
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
Barring objections I'll post a patch to do this tomorrow.
--
Craig Ringer
-Original Message-
From: Simon Riggs [mailto:si...@2ndquadrant.com]
Sent: Wednesday, May 07, 2014 5:02 PM
To: Kaigai Kouhei(海外 浩平)
Cc: Tom Lane; Robert Haas; Andres Freund; PgHacker; Stephen Frost; Shigeru
Hanada; Jim Mlodgenski; Peter Eisentraut; Kohei KaiGai
Subject: Re:
On 7 May 2014 10:06, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
Let me list up the things to be clarified / developed randomly.
* Join replacement by FDW; We still don't have consensus about join
replacement
by FDW. Probably, it will be designed to remote-join implementation
primarily,
Re: Amit Kapila 2014-05-07
caa4ek1ktjkpvmnkos2gfnnh2zsko4ggdspswshjbq1cpu9e...@mail.gmail.com
This problem occurs because we don't have the value of data_directory
set in postgresql.conf by the time we want to parse .auto.conf file
during server start. The value of data_directory is only
So, apart from cleaning up the code, we really need to take a close look
at the on-disk format now. The code can be cleaned up later, too, but
we're going to be stuck with the on-disk format forever, so it's
critical to get that right.
First, a few observations:
* JENTRY_ISFIRST is
On Wed, May 7, 2014 at 8:20 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
So, apart from cleaning up the code, we really need to take a close look at
the on-disk format now. The code can be cleaned up later, too, but we're
going to be stuck with the on-disk format forever, so it's
Hi,
On 2014-05-07 14:20:19 +0300, Heikki Linnakangas wrote:
So, apart from cleaning up the code, we really need to take a close look at
the on-disk format now. The code can be cleaned up later, too, but we're
going to be stuck with the on-disk format forever, so it's critical to get
that
On Wed, May 7, 2014 at 3:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
If we believe that 25% of shared_buffers worth of heap blocks would
flush the cache doing a SeqScan, why should we allow 400% of
shared_buffers worth of index blocks?
I think you're comparing apples and oranges. The 25%
On Wed, May 7, 2014 at 7:40 AM, Andres Freund and...@anarazel.de wrote:
I'm going to proceed refactoring those things, which will change the on-disk
format. It's late in the release cycle - these things really should've been
cleaned up earlier - but it's important to get the on-disk format
On Wed, May 7, 2014 at 1:20 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
So, apart from cleaning up the code, we really need to take a close look
at the on-disk format now. The code can be cleaned up later, too, but we're
going to be stuck with the on-disk format forever, so it's
On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
On Wed, May 7, 2014 at 7:40 AM, Andres Freund and...@anarazel.de wrote:
I don't think it's likely that beta1 will be binary compatible with the
final version at this point.
I rather think we're not ready for beta1 at this point (but I expect
On Wed, May 7, 2014 at 2:56 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
On Wed, May 7, 2014 at 7:40 AM, Andres Freund and...@anarazel.de
wrote:
I don't think it's likely that beta1 will be binary compatible with the
final version at
On 2014-05-07 15:00:01 +0200, Magnus Hagander wrote:
On Wed, May 7, 2014 at 2:56 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
On Wed, May 7, 2014 at 7:40 AM, Andres Freund and...@anarazel.de
wrote:
I don't think it's likely that
On Wed, May 7, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-07 15:00:01 +0200, Magnus Hagander wrote:
On Wed, May 7, 2014 at 2:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
On Wed, May 7, 2014 at 7:40 AM,
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static variable global?.
IOW, no, I don't accept this proposition. Every time we DLLEXPORT some
Magnus Hagander mag...@hagander.net writes:
On Wed, May 7, 2014 at 2:56 PM, Andres Freund and...@2ndquadrant.comwrote:
Well, I guess it depends on what we define 'beta1' to be. Imo evaluating
problematic pieces of new code, locating unfinished pieces is part of
that. I don't see much point in
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static variable global?.
IOW, no, I don't
On 2014-05-07 09:44:36 -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, May 7, 2014 at 2:56 PM, Andres Freund and...@2ndquadrant.comwrote:
Well, I guess it depends on what we define 'beta1' to be. Imo evaluating
problematic pieces of new code, locating unfinished
On 7 May 2014 13:31, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 7, 2014 at 3:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
If we believe that 25% of shared_buffers worth of heap blocks would
flush the cache doing a SeqScan, why should we allow 400% of
shared_buffers worth of index
Simon Riggs si...@2ndquadrant.com writes:
I think I'm arguing myself towards using a BufferAccessStrategy of
BAS_BULKREAD for large IndexScans, BitMapIndexScans and
BitMapHeapScans.
As soon as you've got some hard evidence to present in favor of such
changes, we can discuss it. I've got other
On Wed, May 7, 2014 at 9:07 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
I think I'm arguing myself towards using a BufferAccessStrategy of
BAS_BULKREAD for large IndexScans, BitMapIndexScans and
BitMapHeapScans.
As soon as you've got some hard evidence to
On 2014-05-07 10:07:07 -0400, Tom Lane wrote:
In the meantime, it seems like there is an emerging consensus that nobody
much likes the existing auto-tuning behavior for effective_cache_size,
and that we should revert that in favor of just increasing the fixed
default value significantly. I
On Wed, May 7, 2014 at 10:12 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-07 10:07:07 -0400, Tom Lane wrote:
In the meantime, it seems like there is an emerging consensus that nobody
much likes the existing auto-tuning behavior for effective_cache_size,
and that we should revert
On Wed, May 7, 2014 at 4:12 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-07 10:07:07 -0400, Tom Lane wrote:
In the meantime, it seems like there is an emerging consensus that nobody
much likes the existing auto-tuning behavior for effective_cache_size,
and that we should
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 3:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
If we believe that 25% of shared_buffers worth of heap blocks would
flush the cache doing a SeqScan, why should we allow 400% of
shared_buffers worth of index blocks?
I think
On 07/05/14 02:25, Petr Jelinek wrote:
On 06/05/14 19:05, Robert Haas wrote:
What I'm inclined to do is change the logic so that:
(1) After a crash-and-restart sequence, zero rw-rw_crashed_at, so
that anything which is still registered gets restarted immediately.
Yes, that's quite obvious
On 05/07/2014 09:45 PM, Andres Freund wrote:
I think what Craig actually tries to propose is to mark all GUCs
currently exported in headers PGDLLIMPORT. Currently it's easy to have
extensions that work on sane systems but not windows. If they're already
exposed in headers I don't think changes
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make every
static
On 05/07/2014 10:12 AM, Andres Freund wrote:
On 2014-05-07 10:07:07 -0400, Tom Lane wrote:
In the meantime, it seems like there is an emerging consensus that nobody
much likes the existing auto-tuning behavior for effective_cache_size,
and that we should revert that in favor of just increasing
On 7 May 2014 15:07, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
I think I'm arguing myself towards using a BufferAccessStrategy of
BAS_BULKREAD for large IndexScans, BitMapIndexScans and
BitMapHeapScans.
As soon as you've got some hard evidence to present in
On 7 May 2014 15:10, Merlin Moncure mmonc...@gmail.com wrote:
The core issues are:
1) There is no place to enter total system memory available to the
database in postgresql.conf
2) Memory settings (except for the above) are given as absolute
amounts, not percentages.
Those sound useful
Tom Lane-2 wrote
Andres Freund lt;
andres@
gt; writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer lt;
craig@
gt; writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally equivalent to is there a reason not to make
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
That seems morally
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
To my mind, we PGDLLEXPORT some variable only after deciding that yeah,
we're okay with having third-party modules touching that. Craig's
proposal is to remove human judgement from that process.
It's
Peter Geoghegan p...@heroku.com writes:
On Tue, May 6, 2014 at 8:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The early-exit code path supposes that JB_ROOT_COUNT is absolutely
reliable as an indicator that there's nothing in the jsonb value.
On the other hand, the realloc logic inside the
On Wed, May 7, 2014 at 11:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
To my mind, we PGDLLEXPORT some variable only after deciding that yeah,
we're okay with having third-party modules touching that.
Robert Haas robertmh...@gmail.com writes:
I don't accept this argument. In EnterpriseDB's Advanced Server fork
of PostgreSQL, we've marked a bunch of extra things PGDLLEXPORT
precisely because we have external modules that need access to them.
Well, that's an argument for marking every darn
* Simon Riggs (si...@2ndquadrant.com) wrote:
Agreed. My proposal is that if the planner allows the lookaside to an
FDW then we pass the query for full execution on the FDW. That means
that the scan, aggregate and join could take place via the FDW. i.e.
Custom Plan == lookaside + FDW
How about
On 05/07/2014 06:27 PM, Tom Lane wrote:
I think you're just proving the point that this code is woefully
underdocumented. If there were, somewhere, some comment explaining
what the heck JB_ROOT_COUNT actually counts, maybe I wouldn't be asking
this question. jsonb.h is certainly not divulging
On 2014-05-07 12:21:55 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I don't accept this argument. In EnterpriseDB's Advanced Server fork
of PostgreSQL, we've marked a bunch of extra things PGDLLEXPORT
precisely because we have external modules that need access to them.
* Simon Riggs (si...@2ndquadrant.com) wrote:
IMHO we would not want to add indexes to every column, on every table,
nor would we wish to use lookaside for all tables. It is a good thing
to be able to add optimizations for individual tables. GPUs are not
good for everything; it is good to be
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't accept this argument. In EnterpriseDB's Advanced Server fork
of PostgreSQL, we've marked a bunch of extra things PGDLLEXPORT
precisely because we have external modules that
Heikki Linnakangas hlinnakan...@vmware.com writes:
gin_extract_jsonb recursively extracts all the elements, keys and values
of any sub-object too, but JB_ROOT_COUNT only counts the top-level elements.
Got it. So if the top level is empty, we can exit early, but otherwise we
use its length * 2
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it (after which we'd better debate
exposing the few that are in fact static in
On 2014-05-07 13:08:52 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it (after which we'd better
On Wed, May 7, 2014 at 12:48 AM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2014-05-07 00:35:35 -0700, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure.
On Wed, May 7, 2014 at 1:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 7, 2014 at 12:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If Craig has a concrete argument why all GUCs should be accessible
to external modules, then let's see it (after
On 7 May 2014 17:43, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
IMHO we would not want to add indexes to every column, on every table,
nor would we wish to use lookaside for all tables. It is a good thing
to be able to add optimizations for individual
Hi,
On 2014-05-07 10:21:26 -0700, Jeff Janes wrote:
On Wed, May 7, 2014 at 12:48 AM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2014-05-07 00:35:35 -0700, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 7 May 2014 17:43, Stephen Frost sfr...@snowman.net wrote:
It's the optimizer's job to figure out which path to pick though, based
on which will have the lowest cost.
Of course. I'm not suggesting otherwise.
If do you want that, you can
On 05/07/2014 07:31 AM, Andrew Dunstan wrote:
+1. If we ever want to implement an auto-tuning heuristic it seems we're
going to need some hard empirical evidence to support it, and that
doesn't seem likely to appear any time soon.
4GB default it is, then.
--
Josh Berkus
PostgreSQL Experts
On Wed, May 7, 2014 at 4:40 AM, Andres Freund and...@anarazel.de wrote:
* Imo we need space in jsonb ondisk values to indicate a format
version. We won't fully get this right.
That would be nice.
* The jentry representation should be changed so it's possible to get the type
of a entry
On 05/06/2014 10:35 PM, Peter Geoghegan wrote:
+1. In my view, we probably should have set it to a much higher
absolute default value. The main problem with setting it to any
multiple of shared_buffers that I can see is that shared_buffers is a
very poor proxy for what effective_cache_size is
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
Unfortunately nobody has the time/resources to do the kind of testing
required for a new recommendation for shared_buffers.
I meant to suggest that the buffer manager could be improved to the
point that the old advice becomes
On 2014-05-07 10:55:28 -0700, Peter Geoghegan wrote:
On Wed, May 7, 2014 at 4:40 AM, Andres Freund and...@anarazel.de wrote:
* The jentry representation should be changed so it's possible to get the
type
of a entry without checking individual types. That'll make code like
On Tue, May 6, 2014 at 9:55 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-06 17:43:45 +0100, Simon Riggs wrote:
All this changes is the cost of
IndexScans that would use more than 25% of shared_buffers worth of
data. Hopefully not many of those in your workload. Changing the
On Wed, May 7, 2014 at 1:13 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
Unfortunately nobody has the time/resources to do the kind of testing
required for a new recommendation for shared_buffers.
I meant to suggest that the
I've complained about this problem a few times before: there's nothing
to prevent a background worker which doesn't request shared memory
access from calling InitProcess() and then accessing shared memory
anyway. The attached patch is a first crack at fixing it.
Unfortunately, there's still a
On 2014-05-07 13:32:41 -0500, Merlin Moncure wrote:
On Wed, May 7, 2014 at 1:13 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
Unfortunately nobody has the time/resources to do the kind of testing
required for a new
On 05/07/2014 11:13 AM, Peter Geoghegan wrote:
We ought to be realistic about the fact that the current
recommendations around sizing shared_buffers are nothing more than
folk wisdom. That's the best we have right now, but that seems quite
unsatisfactory to me.
So, as one of several people
Robert Haas robertmh...@gmail.com writes:
I've complained about this problem a few times before: there's nothing
to prevent a background worker which doesn't request shared memory
access from calling InitProcess() and then accessing shared memory
anyway. The attached patch is a first crack at
On Wed, May 7, 2014 at 11:38 AM, Andres Freund and...@2ndquadrant.com wrote:
*) raising shared buffers does not 'give more memory to postgres for
caching' -- it can only reduce it via double paging
That's absolutely not a necessary consequence. If pages are in s_b for a
while the OS will be
Andres Freund and...@anarazel.de writes:
* The jentry representation should be changed so it's possible to get the type
of a entry without checking individual types. That'll make code like
findJsonbValueFromSuperHeader() (well, whatever you've renamed it to)
much easier to read.
On Wed, May 7, 2014 at 2:40 PM, Josh Berkus j...@agliodbs.com wrote:
On 05/07/2014 11:13 AM, Peter Geoghegan wrote:
We ought to be realistic about the fact that the current
recommendations around sizing shared_buffers are nothing more than
folk wisdom. That's the best we have right now, but
On 2014-05-07 11:45:04 -0700, Peter Geoghegan wrote:
On Wed, May 7, 2014 at 11:38 AM, Andres Freund and...@2ndquadrant.com wrote:
*) raising shared buffers does not 'give more memory to postgres for
caching' -- it can only reduce it via double paging
That's absolutely not a necessary
On Wed, May 7, 2014 at 2:49 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-07 11:45:04 -0700, Peter Geoghegan wrote:
On Wed, May 7, 2014 at 11:38 AM, Andres Freund and...@2ndquadrant.com
wrote:
*) raising shared buffers does not 'give more memory to postgres for
caching' -- it
On 2014-05-07 14:48:51 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
* The jentry representation should be changed so it's possible to get the
type
of a entry without checking individual types. That'll make code like
findJsonbValueFromSuperHeader() (well, whatever
On Wed, May 7, 2014 at 11:40 AM, Josh Berkus j...@agliodbs.com wrote:
So, as one of several people who put literally hundreds of hours into
the original benchmarking which established the sizing recommendations
for shared_buffers (and other settings), I find the phrase folk wisdom
personally
On Wed, May 7, 2014 at 2:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I've complained about this problem a few times before: there's nothing
to prevent a background worker which doesn't request shared memory
access from calling InitProcess() and then
On Wed, May 7, 2014 at 11:50 AM, Robert Haas robertmh...@gmail.com wrote:
But that does not mean, as the phrase folk
wisdom might be taken to imply, that we don't know anything at all
about what actually works well in practice.
Folk wisdom doesn't imply that. It implies that we think this
On 07/05/14 20:37, Robert Haas wrote:
At a minimum, it's got to be better than the status quo, where shared
memory is accessible throughout the entire lifetime of
non-shmem-access background workers.
Seems reasonable to me, it might need to be revisited to at least try to
figure out if we
On 05/07/2014 02:52 PM, Andres Freund wrote:
On 2014-05-07 14:48:51 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
* The jentry representation should be changed so it's possible to get the type
of a entry without checking individual types. That'll make code like
On 05/07/2014 11:52 AM, Peter Geoghegan wrote:
On Wed, May 7, 2014 at 11:40 AM, Josh Berkus j...@agliodbs.com wrote:
So, as one of several people who put literally hundreds of hours into
the original benchmarking which established the sizing recommendations
for shared_buffers (and other
btw ... in jsonb.h there is this comment:
* Jsonb Keys and string array elements are treated equivalently when
* serialized to text index storage. One day we may wish to create an opclass
* that only indexes values, but for now keys and values are stored in GIN
* indexes in a way that
On Wed, May 7, 2014 at 11:50 AM, Robert Haas robertmh...@gmail.com wrote:
Doesn't match my experience. Even with the current buffer manager
there's usually enough locality to keep important pages in s_b for a
meaningful time. I *have* seen workloads that should have fit into
memory not fit
On Wed, May 7, 2014 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Jsonb Keys and string array elements are treated equivalently when
* serialized to text index storage. One day we may wish to create an opclass
* that only indexes values, but for now keys and values are stored in GIN
*
And while I'm looking at it ...
The jsonb_ops storage format for values is inherently lossy, because it
cannot distinguish the string values n, t, f from JSON null or
boolean true, false respectively; nor does it know the difference between
a number and a string containing digits. This appears
On Wed, May 7, 2014 at 2:58 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 7, 2014 at 11:50 AM, Robert Haas robertmh...@gmail.com wrote:
But that does not mean, as the phrase folk
wisdom might be taken to imply, that we don't know anything at all
about what actually works well in
On Wed, May 7, 2014 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The jsonb_ops storage format for values is inherently lossy, because it
cannot distinguish the string values n, t, f from JSON null or
boolean true, false respectively; nor does it know the difference between
a number and a
Peter Geoghegan p...@heroku.com writes:
On Wed, May 7, 2014 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is this an obsolete speculation about writing jsonb_hash_ops, or is there
still something worth preserving there? If so, what?
This is not obsolete. It would equally apply to a GiST
On Wed, May 7, 2014 at 10:34 AM, Andres Freund and...@2ndquadrant.comwrote:
Hi,
On 2014-05-07 10:21:26 -0700, Jeff Janes wrote:
On Wed, May 7, 2014 at 12:48 AM, Andres Freund and...@2ndquadrant.com
wrote:
If you have the WAL a pg_xlogdump grepping for everything referring to
that
Peter Geoghegan p...@heroku.com writes:
On Wed, May 7, 2014 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The jsonb_ops storage format for values is inherently lossy, because it
cannot distinguish the string values n, t, f from JSON null or
boolean true, false respectively; nor does it know
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek p...@2ndquadrant.com wrote:
What I'm inclined to do is change the logic so that:
(1) After a crash-and-restart sequence, zero rw-rw_crashed_at, so
that anything which is still registered gets restarted immediately.
Yes, that's quite obvious change
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
On 05/06/2014 10:35 PM, Peter Geoghegan wrote:
+1. In my view, we probably should have set it to a much higher
absolute default value. The main problem with setting it to any
multiple of shared_buffers that I can see is
I wrote:
The readability of that comment starts to go downhill with its use of
reset to refer to what everything else calls a recheck flag, and in
any case it's claiming that we *don't* need a recheck for exists (a
statement I suspect to be false, but more later).
And, indeed, it's false:
On 05/07/2014 10:35 AM, Jeff Janes wrote:
When recovering from a crash (with injection of a partial page write at
time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
verification failure.
16396 is a gin index.
If I have it ignore checksum failures, there is no apparent
I wrote:
Another idea would be to change the definition of the exists operator
so that it *does* look into sub-objects. It seems rather random to me
that containment looks into sub-objects but exists doesn't. However,
possibly there are good reasons for the non-orthogonality.
No, wait,
On 05/07/2014 01:36 PM, Jeff Janes wrote:
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus j...@agliodbs.com wrote:
Unfortunately nobody has the time/resources to do the kind of testing
required for a new recommendation for shared_buffers.
I think it is worse than that. I don't think we know
On Wed, May 7, 2014 at 11:38 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-05-07 13:32:41 -0500, Merlin Moncure wrote:
*) raising shared buffers does not 'give more memory to postgres for
caching' -- it can only reduce it via double paging
That's absolutely not a necessary
On Wed, May 7, 2014 at 1:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, wait, containment *doesn't* look into sub-objects:
regression=# select * from j where f1 @ '{foo: {bar: baz}}';
f1
-
{foo: {bar: baz}}
(1 row)
regression=# select * from j where f1 @
On 07/05/14 22:32, Robert Haas wrote:
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I've committed the portion of your patch which does this, with pretty
extensive changes. I moved the function which resets the crash times
to bgworker.c, renamed it, and made it just
1 - 100 of 135 matches
Mail list logo
