> On 7 May 2014 02:05, Kouhei Kaigai 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 like to
On 6 May 2014 17:55, Andres Freund 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 there are many
>> o
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 tak
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?
> I
On Tue, May 6, 2014 at 7:04 PM, Christoph Berg 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 (/etc/postgresql/9.4/main)
On 7 May 2014 08:17, Kouhei Kaigai 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 that proposes bu
On 05/06/2014 11:30 PM, Peter Geoghegan wrote:
On Tue, May 6, 2014 at 12:48 PM, Andres Freund 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 adjustments.
I'm a
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 ht
> -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 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,
> however, thi
Re: Amit Kapila 2014-05-07
> 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 available after
> processing of config files. To fix it, we need to
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 redundant.
On Wed, May 7, 2014 at 8:20 PM, 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 rig
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 r
On Wed, May 7, 2014 at 3:18 AM, Simon Riggs 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% threshold is
answer
On Wed, May 7, 2014 at 7:40 AM, Andres Freund 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 right.
>> Shout i
On Wed, May 7, 2014 at 1:20 PM, 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 rig
On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
> On Wed, May 7, 2014 at 7:40 AM, Andres Freund 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
> to lose t
On Wed, May 7, 2014 at 2:56 PM, Andres Freund wrote:
> On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
> > On Wed, May 7, 2014 at 7:40 AM, Andres Freund
> wrote:
> > > I don't think it's likely that beta1 will be binary compatible with the
> > > final version at this point.
> >
> > I rather thin
On 2014-05-07 15:00:01 +0200, Magnus Hagander wrote:
> On Wed, May 7, 2014 at 2:56 PM, Andres Freund wrote:
>
> > On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
> > > On Wed, May 7, 2014 at 7:40 AM, Andres Freund
> > wrote:
> > > > I don't think it's likely that beta1 will be binary compatible
On Wed, May 7, 2014 at 3:04 PM, Andres Freund wrote:
> On 2014-05-07 15:00:01 +0200, Magnus Hagander wrote:
> > On Wed, May 7, 2014 at 2:56 PM, Andres Freund >wrote:
> >
> > > On 2014-05-07 08:50:33 -0400, Robert Haas wrote:
> > > > On Wed, May 7, 2014 at 7:40 AM, Andres Freund
> > > wrote:
> >
Craig Ringer 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
variable, we lose the
Magnus Hagander writes:
> On Wed, May 7, 2014 at 2:56 PM, Andres Freund wrote:
>> 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 forbidding incompatible changes in
On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
> Craig Ringer 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 pro
On 2014-05-07 09:44:36 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, May 7, 2014 at 2:56 PM, Andres Freund wrote:
> >> 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
On 7 May 2014 13:31, Robert Haas wrote:
> On Wed, May 7, 2014 at 3:18 AM, Simon Riggs 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
Simon Riggs 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 things to do besid
On Wed, May 7, 2014 at 9:07 AM, Tom Lane wrote:
> Simon Riggs 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
> cha
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 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
On Wed, May 7, 2014 at 4:12 PM, 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
Robert Haas writes:
> On Wed, May 7, 2014 at 3:18 AM, Simon Riggs 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.
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 ch
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 chan
Andres Freund writes:
> On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
>> Craig Ringer 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?".
> I think
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 wrote:
> Simon Riggs 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 ca
On 7 May 2014 15:10, Merlin Moncure 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 starting points.
Tom Lane-2 wrote
> Andres Freund <
> andres@
> > writes:
>> On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
>>> Craig Ringer <
> craig@
> > writes:
Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
concerns?
>
>>> That seems morally equivalent to "is there a reason
On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-07 09:35:06 -0400, Tom Lane wrote:
> >> Craig Ringer writes:
> >>> Is there any reason _not_ to PGDLLEXPORT all GUCs, other than cosmetic
> >>> concerns?
>
> >> That seems morally equivalent to "is there a reaso
Andres Freund 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 just levelling
Peter Geoghegan writes:
> On Tue, May 6, 2014 at 8:08 PM, Tom Lane 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 iteration loop implies
>> that JB
On Wed, May 7, 2014 at 11:19 AM, Tom Lane wrote:
> Andres Freund 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 hu
Robert Haas 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 global variable as
P
* 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
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 a
On 2014-05-07 12:21:55 -0400, Tom Lane wrote:
> Robert Haas 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
* 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 wrote:
> Robert Haas 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
Heikki Linnakangas 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 as a guess at how big
Robert Haas writes:
> On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 guc.c).
> I think there's actually
On 2014-05-07 13:08:52 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 a
On Wed, May 7, 2014 at 12:48 AM, Andres Freund wrote:
> 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
On Wed, May 7, 2014 at 1:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 7, 2014 at 12:21 PM, Tom Lane 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 ar
On 7 May 2014 17:43, Stephen Frost 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 tables. GPUs
Hi,
On 2014-05-07 10:21:26 -0700, Jeff Janes wrote:
> On Wed, May 7, 2014 at 12:48 AM, Andres Freund wrote:
>
> > 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 7c7b1f4ae5ea3b1b
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 7 May 2014 17:43, Stephen Frost 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 write an E
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 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 without checking
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
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus 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 obsolete. Right
On 2014-05-07 10:55:28 -0700, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 4:40 AM, Andres Freund 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
> > findJsonbValueFromSup
On Tue, May 6, 2014 at 9:55 AM, Andres Freund wrote:
> 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 cost
> > doesn
On Wed, May 7, 2014 at 1:13 PM, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 11:04 AM, Josh Berkus 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 im
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 wind
On 2014-05-07 13:32:41 -0500, Merlin Moncure wrote:
> On Wed, May 7, 2014 at 1:13 PM, Peter Geoghegan wrote:
> > On Wed, May 7, 2014 at 11:04 AM, Josh Berkus wrote:
> >> Unfortunately nobody has the time/resources to do the kind of testing
> >> required for a new recommendation for shared_buffers
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 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 fixing it.
> Com
On Wed, May 7, 2014 at 11:38 AM, Andres Freund 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 perfectly happy t
Andres Freund 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. Preferrably so it an ha
On Wed, May 7, 2014 at 2:40 PM, Josh Berkus 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 that seems qu
On 2014-05-07 11:45:04 -0700, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 11:38 AM, Andres Freund 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
On Wed, May 7, 2014 at 2:49 PM, Andres Freund wrote:
> On 2014-05-07 11:45:04 -0700, Peter Geoghegan wrote:
>> On Wed, May 7, 2014 at 11:38 AM, Andres Freund
>> wrote:
>> >> *) raising shared buffers does not 'give more memory to postgres for
>> >> caching' -- it can only reduce it via double pa
On 2014-05-07 14:48:51 -0400, Tom Lane wrote:
> Andres Freund 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 rena
On Wed, May 7, 2014 at 11:40 AM, Josh Berkus 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 offensive. S
On Wed, May 7, 2014 at 2:44 PM, Tom Lane wrote:
> Robert Haas 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. T
On Wed, May 7, 2014 at 11:50 AM, Robert Haas 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 works,
and we may wel
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 can
On 05/07/2014 02:52 PM, Andres Freund wrote:
On 2014-05-07 14:48:51 -0400, Tom Lane wrote:
Andres Freund 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
findJsonbValueFromSuperHea
On 05/07/2014 11:52 AM, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 11:40 AM, Josh Berkus 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
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 doesn't
On Wed, May 7, 2014 at 11:50 AM, Robert Haas 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 because of double
On Wed, May 7, 2014 at 12:08 PM, Tom Lane 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
> * indexes in a w
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 appe
On Wed, May 7, 2014 at 2:58 PM, Peter Geoghegan wrote:
> On Wed, May 7, 2014 at 11:50 AM, Robert Haas 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
On Wed, May 7, 2014 at 12:27 PM, Tom Lane 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 string cont
Peter Geoghegan writes:
> On Wed, May 7, 2014 at 12:08 PM, Tom Lane 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 opclass that
> wanted to suppo
On Wed, May 7, 2014 at 10:34 AM, Andres Freund wrote:
> Hi,
>
> On 2014-05-07 10:21:26 -0700, Jeff Janes wrote:
> > On Wed, May 7, 2014 at 12:48 AM, Andres Freund >wrote:
> > > If you have the WAL a pg_xlogdump grepping for everything referring to
> > > that block would be helpful.
> > >
> >
> >
Peter Geoghegan writes:
> On Wed, May 7, 2014 at 12:27 PM, Tom Lane 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 betwee
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek 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 which I m
On Wed, May 7, 2014 at 11:04 AM, Josh Berkus 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 that shared
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 fal
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 misbehavior
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, c
On 05/07/2014 01:36 PM, Jeff Janes wrote:
> On Wed, May 7, 2014 at 11:04 AM, Josh Berkus 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 what such test
On Wed, May 7, 2014 at 11:38 AM, Andres Freund wrote:
> 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 consequence. If pag
On Wed, May 7, 2014 at 1:47 PM, Tom Lane 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 f
On 07/05/14 22:32, Robert Haas wrote:
On Tue, May 6, 2014 at 8:25 PM, Petr Jelinek 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 reset all of the crash
On Wed, May 7, 2014 at 1:51 PM, Peter Geoghegan wrote:
> Yes it does. It's just not intended to work like that. You have to
> "give a path" to what you're looking for.
There is exactly one exception explicitly noted as such in the
user-visible docs, which is arrays and the containment of single
On 2014-05-07 13:51:57 -0700, Jeff Janes wrote:
> On Wed, May 7, 2014 at 11:38 AM, Andres Freund wrote:
>
> > 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 pagi
1 - 100 of 134 matches
Mail list logo
