>
> > Can a user do anything remotely interesting or useful without hitting
> either
> > ExecutorStart_hook or ProcessUtility_hook? They can parse queries I guess
> > but you could just set your hook up in the parser instead. If you hook
> the
> > parser all they can do is open an idle session and
>
>
> But that seems pretty ugly. Given the lack of previous reports, I'm
> personally content to leave this unfixed in the back branches.
>
> Comments?
>
> Most instances of this I've seen out in the field have worked around this
by just running analyze in the scheduled jobs after the refresh so
On Wed, Mar 1, 2017 at 8:39 PM, Michael Paquier
wrote:
> On Thu, Mar 2, 2017 at 7:20 AM, Jim Mlodgenski wrote:
> >
> >
> > On Sun, Feb 26, 2017 at 11:49 AM, Robert Haas
> wrote:
> >>
> >> On Wed, Feb 22, 2017 at 11:13 AM, Jim Nasby
> >> wro
On Sun, Feb 26, 2017 at 11:49 AM, Robert Haas wrote:
> On Wed, Feb 22, 2017 at 11:13 AM, Jim Nasby
> wrote:
> > Certainly easier, but I don't think it'd be better. Matviews really
> aren't
> > the same thing as tables. Off-hand (without reviewing the patch), update
> and
> > delete counts certai
On Wed, Feb 22, 2017 at 12:43 AM, Jim Nasby
wrote:
> On 2/21/17 4:22 PM, Peter Eisentraut wrote:
>
>> Attached is a patch to trigger autovacuum based on a matview refresh
>>> along with a system view pg_stat_all_matviews to show information more
>>> meaningful for materialized views.
>>>
>> It mi
I've come across a number of times where the statistics on materialized
views become stale producing bad plans. It turns out that autovacuum only
touches a materialized view when it is first created and ignores it on a
refresh. When you have a materialized view like yesterdays_sales the data
in the
On Thu, Jul 21, 2016 at 12:57 AM, David Fetter wrote:
> Folks,
>
> Please find attached a patch which makes it possible to disallow
> UPDATEs and DELETEs which lack a WHERE clause. As this changes query
> behavior, I've made the new GUCs PGC_SUSET.
>
> What say?
>
>
Can't you implement this as a
KaiGai
On Tue, Nov 19, 2013 at 9:41 AM, Kohei KaiGai wrote:
> Thanks for your review.
>
> 2013/11/19 Jim Mlodgenski :
> > My initial review on this feature:
> > - The patches apply and build, but it produces a warning:
> > ctidscan.c: In function ‘CTidInitCustomScan
On Mon, Nov 18, 2013 at 7:25 AM, Kohei KaiGai wrote:
> The attached patches are the revised custom-scan APIs.
>
My initial review on this feature:
- The patches apply and build, but it produces a warning:
ctidscan.c: In function ‘CTidInitCustomScanPlan’:
ctidscan.c:362:9: warning: unused variabl
On Tue, Jan 24, 2012 at 7:38 AM, Heikki Linnakangas
wrote:
> On 23.01.2012 22:52, Jim Mlodgenski wrote:
>>
>> On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenski wrote:
>>>
>>> On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
>>>>
>>>> I do
On Wed, Jan 18, 2012 at 9:19 AM, Jim Mlodgenski wrote:
> On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
> wrote:
>> On 18.01.2012 07:49, Fujii Masao wrote:
>>>
>>> On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenski wrote:
>>>>
>>>> I have
On Wed, Jan 18, 2012 at 3:08 AM, Heikki Linnakangas
wrote:
> On 18.01.2012 07:49, Fujii Masao wrote:
>>
>> On Fri, Jan 6, 2012 at 1:38 AM, Jim Mlodgenski wrote:
>>>
>>> I have a need to send banner messages to a psql client that I can set
>>> on th
I have a need to send banner messages to a psql client that I can set
on the server and will be displayed on any psql client that connects
to the database. This would be mostly used as an additional indicator
to which database you are connecting, but could also be used by people
to force their user
y.
As a data point, I did a read only pgbench test and found that the
standby runs about 15% slower than the primary with identical hardware
and configs.
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your s
14 matches
Mail list logo
