On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Meanwhile, here is an updated patch.
>
> I don't care for that patch too much: it seems a bit brute-force, and I'm
> quite worried by the assumption that it's okay to destroy each child's
> append_rel_list after processing
On Sat, Jun 20, 2015 at 7:01 PM, Tom Lane wrote:
>> If we arranged things so that the processes could use the data in the
>> DSM directly rather than having to copy it out, we'd presumably save
>> quite a bit of memory, since the whole structure would be shared
>> rather than each backend having i
Robert Haas wrote:
> If we arranged things so that the processes could use the data in the
> DSM directly rather than having to copy it out, we'd presumably save
> quite a bit of memory, since the whole structure would be shared
> rather than each backend having its own copy. But if the structure
Robert Haas writes:
> On Sat, Jun 20, 2015 at 6:15 PM, Tom Lane wrote:
>> Hmmm. This sounds attractive, but what happens if we fail to create
>> a new DSM when needed?
> Presumably you keep using the old one and retry later. I mean, out of
> memory is out of memory; you can't move a variable-s
Hi,
On 06/21/2015 12:15 AM, Tom Lane wrote:
Robert Haas writes:
One idea would be to advertise a DSM ID in the main shared memory
segment, and have the individual backends read that value and attach
to it. When new stats are generated, the stats collector creates a
new DSM (which might be big
On Sat, Jun 20, 2015 at 6:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> One idea would be to advertise a DSM ID in the main shared memory
>> segment, and have the individual backends read that value and attach
>> to it. When new stats are generated, the stats collector creates a
>> new DSM (wh
Robert Haas writes:
> Meanwhile, here is an updated patch.
I don't care for that patch too much: it seems a bit brute-force, and I'm
quite worried by the assumption that it's okay to destroy each child's
append_rel_list after processing the child. That would fail if any of
the Vars/subexpression
Robert Haas writes:
> One idea would be to advertise a DSM ID in the main shared memory
> segment, and have the individual backends read that value and attach
> to it. When new stats are generated, the stats collector creates a
> new DSM (which might be bigger or smaller than the old one), writes
On Sat, Jun 20, 2015 at 6:53 AM, Michael Paquier
wrote:
> On Sat, Jun 20, 2015 at 12:44 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> On 2015-06-19 11:16:18 -0400, Robert Haas wrote:
On Fri, Jun 19, 2015 at 11:07 AM, Tom Lane wrote:
> I wonder whether it's such a good idea for the p
On Wed, Jun 17, 2015 at 3:36 AM, Prakash Itnal wrote:
> Currently we observed that certain postgres child process, for eg.
> autovacuum worker, are not working as expected if there is a system time
> change. So I wanted to know if postgres already supports system time changes
> or not.
>
> Please
On Sat, Jun 20, 2015 at 11:15 AM, Magnus Hagander wrote:
> I've considered both that and to perhaps use a shared memory message queue
> to communicate. Basically, have a backend send a request when it needs a
> snapshot of the stats data and get a copy back through that method instead
> of disk. I
El vie., 19 jun. 2015 a las 15:06, Simon Riggs ()
escribió:
> It doesn't say anything about their being only one index buffer per table,
> nor do I think it would make sense to do it that way. So ISTM that the
> foreground process still has to insert serially into N index buffers, with
> each inse
Alvaro Herrera wrote:
> So it turns out we don't have any locking here at all. I don't believe
> we have it for all object types, but in most cases it's not as obnoxious
> as this one. But at least for relations we have some nice coding in
> RangeVarGetRelidExtended and RangeVarGetAndCheckCreati
Vik Fearing wrote:
> Session 1:
> begin;
> alter default privileges in schema bug grant all on tables to postgres;
>
> Session 2:
> alter default privileges in schema bug grant all on tables to postgres;
>
>
> Session 1:
> commit;
>
> Session 2:
> ERROR: tuple concurrently updated
So it turn
Hi,
On 06/20/2015 03:01 AM, Jeff Janes wrote:
Hmmm, that's probably true. OTOH correlated columns are not all that
uncommon (e.g. table storing time-series data etc.), and this blowup
is quite bad ...
True, but we don't know how big of a problem the density-skew
problem might be (
Simon Riggs writes:
> On 20 June 2015 at 18:19, Tom Lane wrote:
>> The key question here is whether filtering functions/operators at the
>> level of extensions is a good design. It seems to me like a reasonable
>> compromise between flexibility and ease of use, but others might see it
>> differe
On 20 June 2015 at 18:19, Tom Lane wrote:
> The key question here is whether filtering functions/operators at the
> level of extensions is a good design. It seems to me like a reasonable
> compromise between flexibility and ease of use, but others might see it
> differently.
I like that, but
Prakash Itnal writes:
> Sorry for the late response. The current patch only fixes the scenario-1
> listed below. It will not address the scenario-2. Also we need a fix in
> unix_latch.c where the remaining sleep time is evaluated, if latch is woken
> by other events (or result=0). Here to it is po
On 06/20/2015 11:32 AM, Tom Lane wrote:
Magnus Hagander writes:
On Sat, Jun 20, 2015 at 10:55 AM, Tom Lane wrote:
I dunno that tweaking the format would accomplish much. Where I'd love
to get to is to not have to write the data to disk at all (except at
shutdown). But that seems to require
Paul Ramsey writes:
> ... I think the postgres_fdw extension should pass user-defined
> functions and operators, but only when it knows those functions and
> operators exist at the remote. One way would be to ask the remote what
> extensions it has, but the overhead of doing that is a bit high. A
Peter Eisentraut writes:
> With the recently released Perl 5.22.0, the tests fail thus:
> -ERROR: Global symbol "$global" requires explicit package name at line 3.
> -Global symbol "$other_global" requires explicit package name at line 4.
> +ERROR: Global symbol "$global" requires explicit packa
On 06/20/2015 10:20 AM, Paul Ramsey wrote:
I would like to enhance the postgres_fdw to allow more complete support for
user-defined types.
Right now, postgres_fdw already does a good job of passing user-defined type
data back and forth, which is pretty nice. However, it will not pass functions
Hi,
On 06/20/2015 05:29 PM, Feng Tian wrote:
I have not read Jeff's patch, but here is how I think hash agg should work,
Hash agg scan lineitem table, perform aggregation in memory. Once
workmem is exhausted, it write intermediate state to disk, bucket by
bucket. When lineitem table is fini
Feng Tian wrote:
> I have not read Jeff's patch, but here is how I think hash agg should work,
I think you should discuss that in Jeff's thread, not here.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sen
Magnus Hagander writes:
> On Sat, Jun 20, 2015 at 10:55 AM, Tom Lane wrote:
>> I dunno that tweaking the format would accomplish much. Where I'd love
>> to get to is to not have to write the data to disk at all (except at
>> shutdown). But that seems to require an adjustable-size shared memory
On Sat, Jun 20, 2015 at 7:56 AM, Tomas Vondra
wrote:
> Hi,
>
> On 06/20/2015 08:54 AM, Feng Tian wrote:
>
>>
>> While better sample/stats is important for choosing a good plan, in
>> this query, hash agg is really the right plan. If a sort agg is
>> chosen, the performance will be really really b
On 06/20/2015 04:17 PM, Robert Haas wrote:
On Wed, Jun 17, 2015 at 1:52 PM, Tomas Vondra
wrote:
I'm currently running some tests on a 3TB TPC-H data set, and I
tripped over a pretty bad n_distinct underestimate, causing OOM in
>> HashAgg (which somehow illustrates the importance of the
>> me
On Sat, Jun 20, 2015 at 10:55 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson
> wrote:
> >> I guess it
> >> primarily depends on how much of the new code that would need to be
> >> rewritten, if the collector is optimized/rewritten in the future?
>
Robert Haas writes:
> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson wrote:
>> I guess it
>> primarily depends on how much of the new code that would need to be
>> rewritten, if the collector is optimized/rewritten in the future?
> I don't think that's really the issue. It's more that I think
Hi,
On 06/20/2015 08:54 AM, Feng Tian wrote:
While better sample/stats is important for choosing a good plan, in
this query, hash agg is really the right plan. If a sort agg is
chosen, the performance will be really really bad. The patch that
Jeff is working on is critical for a decent TPCH num
I would like to enhance the postgres_fdw to allow more complete support for
user-defined types.
Right now, postgres_fdw already does a good job of passing user-defined type
data back and forth, which is pretty nice. However, it will not pass functions
or operators that use user-defined types t
On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson wrote:
> Is there any chance the project would accept a patch which adds the
> pg_stat_*_columns-feature without first optimizing the collector?
I doubt it. It's such a pain point already that massively increasing
the amount of data we need to stor
On Wed, Jun 17, 2015 at 1:52 PM, Tomas Vondra
wrote:
> I'm currently running some tests on a 3TB TPC-H data set, and I tripped over
> a pretty bad n_distinct underestimate, causing OOM in HashAgg (which somehow
> illustrates the importance of the memory-bounded hashagg patch Jeff Davis is
> workin
On Tue, Jun 16, 2015 at 4:47 AM, Jim Nasby wrote:
> Magnus idea was to first optimize the collector to make it less of a
>> problem to collect more data. Sounds like a good thing to do, but maybe
>> more data in it wouldn't be a problem as long as you don't read too
>> often from it?
>>
>
> The s
On Sat, Jun 20, 2015 at 12:24 AM, Alvaro Herrera
wrote:
> Has anybody noticed the way castoroides is randomly failing?
>
> SELECT test_shm_mq_pipelined(16384, (select
> string_agg(chr(32+(random()*95)::int), '') from generate_series(1,27)),
> 200, 3);
> ! PANIC: stuck spinlock (100cb92f4)
Hi,
Sorry for the late response. The current patch only fixes the scenario-1
listed below. It will not address the scenario-2. Also we need a fix in
unix_latch.c where the remaining sleep time is evaluated, if latch is woken
by other events (or result=0). Here to it is possible the latch might go
On Sat, Jun 20, 2015 at 7:06 AM, Michael Paquier
wrote:
>> As far as the
>> rest of this patch goes, it seems like it could be made less invasive
>> if the logs got dumped into a subdirectory of tmp_check rather than
>> adding another top-level directory that has to be cleaned?
>
> tmp_check remai
I tend to agree on that bottom line; having this be inconsistent with psql
does not seem like a win.
I'm not clear on why we'd need a full SQL lexer.
So you don't get fooled by semicolons embedded in string literals or
comments.
I take it we ignore those now? I mean, personally, it wouldn
On Fri, Jun 19, 2015 at 9:20 AM, Robert Haas wrote:
> The extraordinarily planning time for query 4 is caused by a
> completely different problem: SearchCatCache eats up huge amounts of
> CPU; its callers are get_attavgwidth and get_typlen. It's not clear
> to me why doubling the number of relati
39 matches
Mail list logo
