On Thu, Dec 17, 2015 at 8:44 PM, Andres Freund wrote:
>
> On 2015-12-17 09:47:57 -0500, Robert Haas wrote:
> > On Tue, Dec 15, 2015 at 7:25 AM, Andres Freund
wrote:
> > > I'd consider using a LWLock instead of a spinlock here. I've seen this
> > > contended in a bunch of situations, and the queue
> Oops, 3.5-4 _times_ more TPS, i.e. 2206 TPS vs 546 TPS.
In fact these numbers are for similar but a little bit different
benchmark (same schema without checks on child tables). Here are exact
numbers for a benchmark described above.
Before:
$ pgbench -j 64 -c 64 -f pgbench.sql -T 30 my_datab
On Thu, Dec 17, 2015 at 9:33 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
>
> > It'd really like to see it being replaced by a queuing lock
> > (i.e. lwlock) before we go there. And then maybe partition the
> > freelist, and make nentries an atomic.
>
> I believe I just implemented s
On Thu, Dec 17, 2015 at 9:13 PM, Tom Lane wrote:
>
> Whether we really need a feature like that isn't clear though; it's not
> like it's hard to test things that way now. Stick in a BEGIN with no
> COMMIT, you're there. The problem only comes in if you start expecting
> the behavior to be bulle
On Fri, Dec 18, 2015 at 7.59 AM Robert Haas Wrote,
> Uh oh. That's not supposed to happen. A GatherPath is supposed to
> have parallel_safe = false, which should prevent the planner from
> using it to form new partial paths. Is this with the latest version
> of the patch? The plan output sugg
> This idea can improve the situation with ProcLock hash table, but I
> think IIUC what Andres is suggesting would reduce the contention
> around dynahash freelist and can be helpful in many more situations
> including BufMapping locks.
I agree. But as I understand PostgreSQL community doesn't gen
On 2015-12-18 11:40:58 +0300, Aleksander Alekseev wrote:
> $ pgbench -j 64 -c 64 -f pgbench.sql -T 30 my_database
What's in pgbench.sql?
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
> What's in pgbench.sql?
It's from first message of this thread:
http://www.postgresql.org/message-id/20151211170001.78ded9d7@fujitsu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-12-17 21:33 GMT+01:00 Pavel Stehule :
>
>
> 2015-12-14 23:09 GMT+01:00 Daniel Verite :
>
>> Pavel Stehule wrote:
>>
>> > postgres=# \crosstabview 4 +month label
>> >
>> > Maybe using optional int order column instead label is better - then
>> you can
>> > do sort on client side
>> >
>
On Fri, Dec 18, 2015 at 2:50 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
>
> > This idea can improve the situation with ProcLock hash table, but I
> > think IIUC what Andres is suggesting would reduce the contention
> > around dynahash freelist and can be helpful in many more situat
Hi All,
Costs for foreign queries are either obtained from the foreign server using
EXPLAIN (if use_remote_estimate is ON) otherwise they are cooked up locally
based on the statistics available. For joins as well, we have to do the
same. If use_remote_estimates [1] is ON, we can get the costs from
Ashutosh Bapat wrote:
> Costs for foreign queries are either obtained from the foreign server using
> EXPLAIN (if
> use_remote_estimate is ON) otherwise they are cooked up locally based on the
> statistics available. For
> joins as well, we have to do the same. If use_remote_estimates [1] is ON,
On Wed, Sep 16, 2015 at 8:01 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Aug 24, 2015 at 8:26 PM, Jeff Janes wrote:
>
>> On Thu, Aug 20, 2015 at 6:00 PM, Tomas Vondra <
>> tomas.von...@2ndquadrant.com> wrote:
>>
>>> Hi,
>>>
>>> On 08/11/2015 04:38 PM, Jeff Janes wrote:
>>
Oh, that's an interesting idea. I guess the problem is that if the
freelist is unshared, then users might get an error that the lock
table is full when some other partition still has elements remaining.
Could we split one freelist in hash to NUM_LOCK_PARTITIONS freelists?
Each partition will ha
On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas wrote:
> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
> wrote:
>> On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote:
>>> The function, maybe. But emitting an all-nulls row from a view seems
>>> counter-intuitive, at least when looking at it in c
> Could we split one freelist in hash to NUM_LOCK_PARTITIONS freelists?
> Each partition will have its own freelist and if freelist is empty
> then partition should search an entry in freelists of other
> partitions. To prevent concurrent access it's needed to add one
> LWLock to hash, each partiti
On Thu, Dec 17, 2015 at 1:51 PM, Kenan Yao wrote:
> Hi there,
>
> In function ProcSleep, after the process has been waken up, either with
> lock granted or deadlock detected, it would re-acquire the lock table's
> partition LWLock.
>
> The code episode is here:
>
> /*
> * Re-acquire the lock
On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas wrote:
> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby wrote:
>> IIUC, that means supporting backwards compat. GUCs for 10 years, which seems
>> a bit excessive. Granted, that's about the worse-case scenario for what I
>> proposed (ie, we'd still be supp
> This idea can improve the situation with ProcLock hash table, but I
> think IIUC what Andres is suggesting would reduce the contention
> around dynahash freelist and can be helpful in many more situations
> including BufMapping locks.
I agree. But as I understand PostgreSQL community doesn't gen
On Fri, Dec 18, 2015 at 3:54 AM, Dilip Kumar wrote:
> On Fri, Dec 18, 2015 at 7.59 AM Robert Haas Wrote,
>> Uh oh. That's not supposed to happen. A GatherPath is supposed to
>> have parallel_safe = false, which should prevent the planner from
>> using it to form new partial paths. Is this with
On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat wrote:
> On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas wrote:
>> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby wrote:
>>> IIUC, that means supporting backwards compat. GUCs for 10 years, which seems
>>> a bit excessive. Granted, that's about the worse-c
On Fri, Dec 18, 2015 at 8:46 AM, Teodor Sigaev wrote:
>> Oh, that's an interesting idea. I guess the problem is that if the
>> freelist is unshared, then users might get an error that the lock
>> table is full when some other partition still has elements remaining.
>
> Could we split one freelist
Robert Haas wrote:
> On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat wrote:
> > Perhaps not with rock solid consistency, but we've certainly used the
> > argument of the "not a major major version release" to shoot down
> > introducing incompatible features / improvements (protocol changes
> > come
Robert Haas writes:
> My experience is that it is very common for users to upgrade across a
> whole series of releases at the same time. People don't upgrade from
> 8.3 to 8.4 and then to 9.0, or even from 8.3 to 9.0 to 9.2. I mean,
> some do. But people doing things like 8.2 -> 9.3 is not that
On Fri, Dec 18, 2015 at 11:08 AM, Alvaro Herrera
wrote:
> I don't know what would be a good reason to change from 9 to 10, but
> certainly we shouldn't do it just to remove a couple of GUCs -- much
> less do it for no reason at all (which would be what "but 9.6 is too
> close to 9.10 already" woul
On Fri, Dec 18, 2015 at 1:16 AM, Amit Kapila wrote:
> 1. At scale factor 300, there is gain of 11% at 128-client count and
> 27% at 256 client count with Patch-1. At 4 clients, the performance with
> Patch is 0.6% less (which might be a run-to-run variation or there could
> be a small regression,
On Fri, Dec 18, 2015 at 8:09 AM, Albe Laurenz wrote:
> My gut feeling is that for a join where all join predicates can be pushed
> down, it
> will usually be a win to push the join to the foreign server.
>
> So in your first scenario, I'd opt for always pushing down the join
> if possible if use_
* Robert Haas (robertmh...@gmail.com) wrote:
> This appears to address one of the open items at
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items -- if so,
> please update that page.
Done (and re-done with the wiki restore).
No open items remain against 9.5.
Thanks!
Stephen
signatu
On Fri, Dec 18, 2015 at 11:40 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> This appears to address one of the open items at
>> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items -- if so,
>> please update that page.
>
> Done (and re-done with the wiki restore)
On Thu, Dec 17, 2015 at 2:55 AM, Peter Geoghegan wrote:
> On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote:
>>> In any case, at this point 9.5 is really aimed to be stabilized, so
>>> targeting only master is a far saner approach IMO for this patch.
>>> Pushing that in 9.5 a couple of mont
On 2015-12-16 19:01:40 -0500, Robert Haas wrote:
> Yeah, there's something to be said for that, although to be honest in
> most cases I'd prefer to wait longer. I wonder about perhaps
> planning to drop things after two lifecycles.
I don't really give a damn in this specific case. Seems to cost
On Fri, Dec 18, 2015 at 1:25 AM, Amit Langote
wrote:
> I think the following may be a typo:
>
> * Caller is responsible for ensuring that no other backend can access the
> * storage underlying this tuple, either by holding an exclusive lock on the
> - * buffer containing it (which is what lazy
On Fri, Dec 18, 2015 at 12:02 PM, Andres Freund wrote:
> On 2015-12-16 19:01:40 -0500, Robert Haas wrote:
>> Yeah, there's something to be said for that, although to be honest in
>> most cases I'd prefer to wait longer. I wonder about perhaps
>> planning to drop things after two lifecycles.
>
>
On Thu, Dec 17, 2015 at 1:17 AM, Michael Paquier
wrote:
> I am not really getting the meaning of this sentence. Shouldn't this
> be reworded something like:
> "Freezing occurs on the whole table once all pages of this relation require
> it."
That statement isn't remotely true, and I don't think
On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
> Well, Tom, Alvaro, and I all pretty much said that removing things
> when it's blocking further development makes sense, but that there's
> no hurry to remove anything else. That sounds like what you are
> saying, too. So what's the actual disagr
I wrote:
> Not entirely sure what to make of this. It occurs to me that the "it
> breaks immutability" argument might apply to array_nulls, though I've
> not done any legwork to confirm or disprove that. If it doesn't apply,
> though, I'm leaning to the position that there's no reason to remove
>
On Thu, Dec 17, 2015 at 2:26 AM, Andres Freund wrote:
> On 2015-12-17 16:22:24 +0900, Michael Paquier wrote:
>> On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund wrote:
>> > On 2015-12-17 15:56:35 +0900, Michael Paquier wrote:
>> >> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs
>> >> wrote:
>> >> >
On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund wrote:
> On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
>> Well, Tom, Alvaro, and I all pretty much said that removing things
>> when it's blocking further development makes sense, but that there's
>> no hurry to remove anything else. That sounds
On 12/18/2015 09:12 AM, Robert Haas wrote:
On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund wrote:
On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
Well, Tom, Alvaro, and I all pretty much said that removing things
when it's blocking further development makes sense, but that there's
no hurry to
On Fri, Dec 18, 2015 at 12:19 PM, Joshua D. Drake
wrote:
> On 12/18/2015 09:12 AM, Robert Haas wrote:
>>
>> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund
>> wrote:
>>>
>>> On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
Well, Tom, Alvaro, and I all pretty much said that removing thi
Robert Haas writes:
> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund wrote:
>> I'm saying that 10 year deprecation periods don't make sense. Either we
>> decide to remove the compat switch because we dislike it for $reasons,
>> in which case it should be removed sooner. Or we decide to keep the
On Thu, Dec 17, 2015 at 11:46 PM, Craig Ringer wrote:
> Trivial fix for a copy-and-paste error in a logical decoding error callback.
Committed and back-patched to 9.5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund
> wrote:
> >> I'm saying that 10 year deprecation periods don't make sense. Either we
> >> decide to remove the compat switch because we dislike it for $reasons,
> >> in w
On Thu, Dec 17, 2015 at 11:43 PM, Peter Geoghegan wrote:
> On Wed, Dec 16, 2015 at 12:04 PM, Peter Geoghegan wrote:
>>> What kind of state is that? Can't we define this in terms of what it
>>> is rather than how it gets that way?
>>
>> It's zeroed.
>>
>> I guess we can update everything, includi
On Wed, Dec 16, 2015 at 1:09 AM, Rushabh Lathia
wrote:
> TupleQueueReaderNext() always pass true for the nowait into
> shm_mq_receive() call. I think here it need to pass the nowait
> which is passed by the caller of TupleQueueReaderNext.
>
> This is usefull if the caller want TupleQueueReaderNext
Just so everyone's on the same page: the release team is currently
assuming that we'll release 9.5.0 the first week of January (ie
wrap on Monday 4 Jan for public announcement Thursday 7 Jan).
And we're thinking that we'll do a round of back-branch updates,
including 9.5.1, the second week of Febru
"David G. Johnston" writes:
> On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane wrote:
>> Maybe I shouldn't put words in Andres' mouth, but I don't think that by
>> "indefinitely" he meant "forever". I read that more as "until some
>> positive reason to remove it arrives". I could imagine that at some
On Wed, Dec 16, 2015 at 3:33 AM, Kyotaro HORIGUCHI
wrote:
> Hello, I think I found a typo in a comment of syncrep.c.
>
>> * acknowledge the commit nor raise ERROR or FATAL. The latter would
>> - * lead the client to believe that that the transaction aborted, which
>> * is not true: it's alrea
On Mon, Dec 14, 2015 at 6:47 AM, Aleksander Alekseev
wrote:
> Here is my fix for item 4.
I don't know, I'm still not very comfortable with this. And Tom
didn't like dictating that hash_any() must be no-fail, though I'm not
sure why.
Let's wait to see what others think. I kind of hope there's a
On Sat, Dec 12, 2015 at 5:28 PM, Peter Geoghegan wrote:
> On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes wrote:
>> I have a question about the terminology used in this patch. What is a
>> tuple proper? What is it in contradistinction to? I would think that
>> a tuple which is located in its own
On Wed, Dec 16, 2015 at 5:02 AM, Jesper Pedersen
wrote:
> On 09/16/2015 12:44 PM, Jesper Pedersen wrote:
>>
>> So, I think there is some value in keeping this information separate.
>>
>
> Just a rebased patch after the excellent LWLockTranche work.
>
> And a new sample report with -c/-j 200 -M pre
On Wed, Dec 16, 2015 at 12:54 AM, Michael Paquier
wrote:
> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote:
>> On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier
>> wrote:
>>> I have looked for now at the first patch and finished with the
>>> attached while looking at it. Perhaps a committer c
On Wed, Dec 16, 2015 at 5:59 AM, David Rowley
wrote:
> One thing I noticed is that you're only enabling Parallel aggregation when
> there's already a Gather node in the plan. Perhaps this is fine for a proof
> of concept, but I'm wondering how we can move forward from this to something
> that can
Robert Haas writes:
> I don't know, I'm still not very comfortable with this. And Tom
> didn't like dictating that hash_any() must be no-fail, though I'm not
> sure why.
What I definitely didn't like was assuming at a distance that it would
be no-fail. If we're to depend on that, the patch had
On Wed, Dec 16, 2015 at 11:51 PM, Tatsuro Yamada
wrote:
> I found typos in privileges.sql and privileges.out
> Please find attached a patch.
Thanks, good catch. But even aside from this particular issue, isn't
that comment in need of a little more love? An inference means a
deduction, or someth
On Fri, Dec 18, 2015 at 10:12 AM, Robert Haas wrote:
> Anyway, I agree with Jeff that this terminology shouldn't creep into
> function and structure member names.
Okay.
> I don't really like the term "memory pool" either. We're growing a
> bunch of little special-purpose allocators all over the
On 2015-12-18 13:50:34 -0500, Robert Haas wrote:
> On Wed, Dec 16, 2015 at 11:51 PM, Tatsuro Yamada
> wrote:
> > I found typos in privileges.sql and privileges.out
> > Please find attached a patch.
>
> Thanks, good catch. But even aside from this particular issue, isn't
> that comment in need of
On Fri, Dec 18, 2015 at 8:58 AM, Robert Haas wrote:
> No, it's far too late to be pushing this into 9.5. We are at RC1 now
> and hoping to cut a final release right after Christmas. I think it's
> quite wrong to argue that these changes have no risk of destabilizing
> 9.5. Nobody is exempt from
On Fri, Dec 18, 2015 at 9:35 AM, Robert Haas wrote:
>> Attached revision updates both the main commit (the optimization), and
>> the backpatch commit (updated the contract).
>
> - /* abbreviation is possible here only for by-reference types */
> + /*
> +* Abbreviation is possib
On 18.12.2015 22:43, Artur Zakirov wrote:
Hello.
PostgreSQL has a contrib module named pg_trgm. It is used to the fuzzy
text search. It provides some functions and operators for determining
the similarity of the given texts using trigram matching.
Sorry, I have forgotten to mark previous me
On Fri, Dec 18, 2015 at 10:12 AM, Robert Haas wrote:
> I don't really like the term "memory pool" either. We're growing a
> bunch of little special-purpose allocators all over the code base
> because of palloc's somewhat dubious performance and memory usage
> characteristics, but if any of those
Pavel Stehule wrote:
> The symbol 'X' in two column mode should be centred - now it is aligned to
> left, what is not nice
Currently print.c does not support centered alignment, only left and right.
Should we add it, it would have to work for all output formats
(except obviously for "unal
Michael Paquier writes:
> OK, I am marking that as ready for committer. Let's see what happens next.
I'll pick this up, as penance for not having done much in this commitfest.
I think it's important to get it pushed quickly so that Thomas doesn't
have to keep tracking unrelated changes in tab-com
Thomas Munro writes:
> [ tab-complete-macrology-v11.patch.gz ]
A couple of stylistic reactions after looking through the patch for the
first time in a long time:
1. It seems inconsistent that all the new macros are named in CamelCase
style, whereas there is still plenty of usage of the existing
On Thu, Dec 17, 2015 at 3:32 AM, Ashutosh Bapat
wrote:
> On Wed, Dec 9, 2015 at 12:14 AM, Robert Haas wrote:
>> On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia
>> wrote:
>> > Thanks Ashutosh.
>> >
>> > Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
>> > looks good to me.
>>
>> Thi
On Fri, Dec 18, 2015 at 2:57 PM, Peter Geoghegan wrote:
> On Fri, Dec 18, 2015 at 10:12 AM, Robert Haas wrote:
>> I don't really like the term "memory pool" either. We're growing a
>> bunch of little special-purpose allocators all over the code base
>> because of palloc's somewhat dubious perfor
On Fri, Dec 18, 2015 at 1:57 PM, Andres Freund wrote:
> On 2015-12-18 13:50:34 -0500, Robert Haas wrote:
>> On Wed, Dec 16, 2015 at 11:51 PM, Tatsuro Yamada
>> wrote:
>> > I found typos in privileges.sql and privileges.out
>> > Please find attached a patch.
>>
>> Thanks, good catch. But even asi
On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote:
> It isn't true that Heikki was not basically in favor of this. This
> should have been committed as part of the original patch, really.
Maybe he wasn't against the whole thing, but he's posted two messages
to this thread and they can't be r
On Fri, Dec 18, 2015 at 12:50 PM, Robert Haas wrote:
>> BTW, I'm not necessarily determined to make the new special-purpose
>> allocator work exactly as proposed. It seemed useful to prioritize
>> simplicity, and currently so there is one big "huge palloc()" with
>> which we blow our memory budget
I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
I can't reproduce it reliably but looking at the coredumps, the failing
part of the e
On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote:
> On Fri, Dec 18, 2015 at 2:04 PM, Peter Geoghegan wrote:
>> It isn't true that Heikki was not basically in favor of this. This
>> should have been committed as part of the original patch, really.
>
> Maybe he wasn't against the whole thing, bu
Hello Michael,
It was definitely useful to debug the double/int type stuff within
expressions when writing a non trivial pgbench script. It is probably less
interesting if there are only integers.
After looking again at the code, I remembered why double are useful: there
are needed for rand
>From documentation about "CREATE DATABASE name WITH TABLESAPCE =
tablespace_name":
tablespace_name
The name of the tablespace that will be associated with the new database,
or DEFAULT to
use the template database's tablespace. This tablespace will be the default
tablespace used
for objects create
On Thu, 17 Dec 2015 at 15:36 Tom Lane wrote:
> Gaetano Mendola writes:
> > I'm playing around with tablespace (postgresq 9.4) and I found out what I
> > believe is a bug in pg_tables.
> > Basically if you create a database in a table space X and then you
> create a
> > table on the database the
On Fri, Dec 18, 2015 at 1:23 PM, Andreas Seltenreich wrote:
> I do see two assertions in spgtextproc.c fail on occasion when testing
> with sqlsmith:
>
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
>
> I can't repr
On 12/18/2015 05:18 PM, Gaetano Mendola wrote:
From documentation about "CREATE DATABASE name WITH TABLESAPCE =
tablespace_name":
tablespace_name
The name of the tablespace that will be associated with the new
database, or DEFAULT to
use the template database's tablespace. This tablespace
On 12/18/15 11:44 AM, Tom Lane wrote:
"David G. Johnston" writes:
>On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane wrote:
>>Maybe I shouldn't put words in Andres' mouth, but I don't think that by
>>"indefinitely" he meant "forever". I read that more as "until some
>>positive reason to remove it a
2015-12-18 21:21 GMT+01:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > The symbol 'X' in two column mode should be centred - now it is aligned
> to
> > left, what is not nice
>
> Currently print.c does not support centered alignment, only left and right.
> Should we add it, it would have
Peter Geoghegan writes:
> Can you do this?:
>
> (gdb) p debug_query_string
output below. Since sqlsmith ist no longer restricted to read-only
statements, the chances for reproduction are low :-/.
select
pg_catalog.pg_stat_get_buf_written_backend() as c0,
subq_1.c0 as c1,
subq_1.c0 as c2,
79 matches
Mail list logo
