I've found an interesting performance problem in the intarray extension
module. It doesn't seem to be version dependent, I've verified it in 9.4.4
and 9.6devel.
If I do a query that involves both an = op and a @@ op ANDed together, it
gives a high cost estimate, which is justified by the slow run
On Sun, Jul 12, 2015 at 5:59 PM, Yaroslav wrote:
> I can still see all statistics for 'test' in pg_stats under unprivileged
> user.
Indeed, this looks like an oversight of RLS. Even if a policy is
defined to prevent a user from seeing the rows of other users, it is
still possible to get some infor
On Tue, Jul 7, 2015 at 7:25 AM, Andres Freund wrote:
> On 2015-06-30 11:35:56 +0200, Andres Freund wrote:
>> On 2015-06-29 22:58:05 -0400, Tom Lane wrote:
>> > So personally, I would be inclined to put back the volatile qualifier,
>> > independently of any fooling around with _Asm_double_magic_xyz
On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi wrote:
>
> I will do some performance tests and send you the results.
Here are the performance results tested on my machine.
Head vm patchvm+prefetch patch
First vacuum120sec<1sec
On Mon, Jul 13, 2015 at 4:06 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Coverity is pointing out a couple of resource leaks:
>> ...
>> Attached is a patch to address all those things. Backpatches would be good
>> to have as well.
>
> I'll take this up, unless some other committer is already
I wrote:
> The two contrib modules this patch added are nowhere near fit for public
> consumption. They cannot clean up after themselves when dropped:
> ...
> Raw inserts into system catalogs just
> aren't a sane thing to do in extensions.
I had some thoughts about how we might fix that, without
On Tue, Jul 07, 2015 at 10:14:49AM -0700, David E. Wheeler wrote:
> On Jul 7, 2015, at 6:41 AM, Andres Freund wrote:
>
> > At the minimum I'd like to see that CREATE EXTENSION foo; would
> > install install extension 'bar' if foo dependended on 'bar' if
> > CASCADE is specified. Right now we alwa
On Sun, Jul 12, 2015 at 05:02:51PM -0400, Andrew Dunstan wrote:
> >>Marco Atzeri writes:
> >>>for what I see the hstore_plperl link has a double problem.
> >>>It requires a link to hstore
> >>>as it also requires a link to perl.
> >>>Attached patch for solving this and a similar issue with python.
On Sun, Jul 12, 2015 at 1:45 PM, Andres Freund wrote:
> But that's more crummy API's fault than yours.
As you probably noticed, the only reason the p_is_update and
p_is_insert fields exist is for transformAssignedExpr() -- in fact, in
the master branch, nothing checks the value of p_is_update (al
Stephen,
> Stephen, would you have the time to review this patch, and commit if
> appropriate, please? And if you could set up the buildfarm animal to run
> this, even better.
I gave this a quick review/test against master (0a0fe2f). Everything
builds and installs as would be expected.
All of t
Andrew Dunstan writes:
>> On 07/04/2015 11:02 AM, Tom Lane wrote:
>>> It's not apparent to me how that works at all.
> BTW, the .a files being linked to above are not like Unix .a static
> archives - they are import library files, which I think they are only
> used at link time, not run time. T
On 07/04/2015 01:09 PM, Andrew Dunstan wrote:
On 07/04/2015 11:02 AM, Tom Lane wrote:
Marco Atzeri writes:
for what I see the hstore_plperl link has a double problem.
It requires a link to hstore
as it also requires a link to perl.
Attached patch for solving this and a similar issue with pyt
On 2015-05-28 14:37:43 -0700, Peter Geoghegan wrote:
> To fix, allow ParseState to reflect that an individual statement can be
> both p_is_insert and p_is_update at the same time.
> /* Process DO UPDATE */
> if (onConflictClause->action == ONCONFLICT_UPDATE)
> {
> + /
Michael Paquier writes:
> Coverity is pointing out a couple of resource leaks:
> ...
> Attached is a patch to address all those things. Backpatches would be good
> to have as well.
I'll take this up, unless some other committer is already on it.
regards, tom lane
--
Se
2015-07-12 20:11 GMT+02:00 Shulgin, Oleksandr
:
> > > we talking about output - I can imagine, so there is only two
> possibilities
> > > - plain join, and pretty formatted join (but with only one style).
> >
> > This makes sense. Postgres core really only needs to support the
> > minimum styles
> > we talking about output - I can imagine, so there is only two
possibilities
> > - plain join, and pretty formatted join (but with only one style).
>
> This makes sense. Postgres core really only needs to support the
> minimum styles necessary for core requirements. This means raw
> unformatte
Robert Haas writes:
> On Sun, Jul 12, 2015 at 12:02 PM, Tom Lane wrote:
>> As best I can tell (evidence below), the SQL standard requires that if a
>> single query reads a table with a TABLESAMPLE clause multiple times (say,
>> because it's on the inside of a nestloop), then the exact same set of
On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule wrote:
>
>
> 2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
> :
>>
>> On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
>> >
>> > There is simple rule - be strict on output and tolerant on input. If I
>> > understand to sense of this patch - the target
On Sun, Jul 12, 2015 at 12:02 PM, Tom Lane wrote:
> As best I can tell (evidence below), the SQL standard requires that if a
> single query reads a table with a TABLESAMPLE clause multiple times (say,
> because it's on the inside of a nestloop), then the exact same set of
> sampled rows are return
(was Re: [COMMITTERS] pgsql: Add transforms feature)
On Tue, May 05, 2015 at 10:24:03PM -0400, Peter Eisentraut wrote:
> Any dlopenable module will have undefined symbols, namely those that it
> uses to call back into the executable that loads the module. The only
> way it can know to not complai
As best I can tell (evidence below), the SQL standard requires that if a
single query reads a table with a TABLESAMPLE clause multiple times (say,
because it's on the inside of a nestloop), then the exact same set of
sampled rows are returned each time. The BERNOULLI code, at least, fails
to achie
Hi all,
Coverity is pointing out a couple of resource leaks:
- In DropReplicationSlot@streamutil.c, query is leaked.
- In getTransforms@pg_dump.c, the alloced result of get_language_name is
not free'd. Other code paths calling this routine do the job.
- In libpqGetCurrentXlogInsertLocation@libpq_f
On Sat, Jul 11, 2015 at 9:28 PM, Andres Freund wrote:
> On 2015-07-11 21:09:05 +0900, Michael Paquier wrote:
> > Something like the patches attached
>
> Thanks for that!
>
> > could be considered, one is for master
> > and REL9_5_STABLE to remove ssl_renegotiation_limit, the second one for
> > ~R
On Thu, Jul 2, 2015 at 7:33 PM, Tom Lane wrote:
>
> Simon Riggs writes:
> > On 2 July 2015 at 14:08, Heikki Linnakangas wrote:
> >> I'm marking this as "returned with feedback" in the commitfest.
>
> > There are no unresolved issues with the approach, nor is it true it is
> > slower. If you thin
Hi, Hackers,
The feature of UPSERT was my most interested one of 9.5, I really like
need it.
I have test the different usages for this features like one record input,
multi records input,
and also more than 10,000 records upserting, all look great, thanks for
your work.
When I checked my record
2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr
:
> On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
> >
> > There is simple rule - be strict on output and tolerant on input. If I
> understand to sense of this patch - the target is one same format of JSON
> documents - so there are no space for any
Hi everyone.
The ParameterStatus message is currently sent for a hard-wired set of
parameters (
http://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-ASYNC
).
Just wanted to let you know that making this more flexible would be a great
help in driver implementation. Npgsql main
Hi.
I've tried RLS for a little (in PostgreSQL 9.5alpha1), and want to ask why
this wasn't taken in account
in its implementation:
"Rather than look at pg_statistic directly, it's better to look at its view
pg_stats when examining the statistics manually. pg_stats is designed to be
more easily re
On Jul 11, 2015 8:41 PM, "Pavel Stehule" wrote:
>
> There is simple rule - be strict on output and tolerant on input. If I
understand to sense of this patch - the target is one same format of JSON
documents - so there are no space for any variability.
So, would you prefer explain json format on a
29 matches
Mail list logo
