As a follow-up question,
I found some of the varchar column types, in which the histogram_bounds are
not being surrounded in double quotes (" ") even in the default
implementation.
Ex : *c_name* column of *Customer* table
I also found histogram_bounds in which only some strings are surrounded in
On Mon, Jul 7, 2014 at 11:46 PM, Greg Stark wrote:
> On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane wrote:
> > I doubt it. The extra code isn't the problem so much, it's the extra
> > planning cycles spent trying to make proofs that will usually fail.
> > What you propose will create a combinatorial
On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila
wrote:
> On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
* Acquire/read barrier semantics.
*/
STATIC_IF_INLINE_DECLARE bool
pg_atomic_test_set_flag(volatile pg_atomic_flag
Hi,
I am trying to implement a functionality that is similar to ANALYZE, but
needs to have different values (the values will be valid and is stored in
inp->str[][]) for MCV/Histogram Bounds in case the column under
consideration is varchar (C Strings). I have written a function
*dummy_update_attst
On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Right now, constraint exclusion code looks only at the provided
> conditions.
> > If we want avoid table scan based on constraints in the above example, it
> > will need to look at the implied conditions as well. E.g. v
On 07/08/2014 07:44 AM, Robert Haas wrote:
> On Sun, Jul 6, 2014 at 4:17 AM, Craig Ringer wrote:
>> After someone reported somewhat less than informative errors in bytea
>> decoding (http://stackoverflow.com/q/24588866/398670) I thought I'd put
>> together a quick patch to improve the errors here.
On 06 July 2014 20:33, Emre Hasegeli Wrote,
>
> > Apart from that there is one spell check you can correct
> > -- in inet_his_inclusion_selec comments histogram boundies ->
> > histogram boundaries :)
>
> I fixed it. New version attached. The debug log statements are also
> removed.
I have do
On Mon, Jul 7, 2014 at 5:50 PM, Robert Haas wrote:
> On Fri, Jul 4, 2014 at 12:36 AM, Rushabh Lathia
> wrote:
> > On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane wrote:
> >> Tom Dunstan writes:
> >> > On 4 July 2014 00:07, Tom Lane wrote:
> >> >> It sounds to me like designing this for JDBC's getGen
On Tue, Jun 24, 2014 at 10:17:49AM -0700, Tom Lane wrote:
> Josh Berkus writes:
> > On 06/23/2014 03:52 PM, Andres Freund wrote:
> >> True. Which makes me wonder whether we shouldn't default this to
> >> something non-zero -- even if it is 5 or 10 days.
>
> > I'd go for even shorter: 48 hours.
On Mon, Jul 7, 2014 at 7:04 PM, Robert Haas wrote:
> The testing I did showed about a 5% overhead on REINDEX INDEX
> pgbench_accounts_pkey from one extra tuple copy (cf.
> 9f03ca915196dfc871804a1f8aad26207f601fd6). Of course that could vary
> by circumstance for a variety of reasons.
Be careful
>From 9.4 psql has slightly changed it's behavior.
Pre 9.4:
psql --version
psql (PostgreSQL) 9.3.4
psql -U '' test
FATAL: no PostgreSQL user name specified in startup packet
psql: FATAL: no PostgreSQL user name specified in startup packet
9.4:
psql -U '' test
psql (9.4beta1, server 9.3.4)
Type
On Mon, Jul 7, 2014 at 5:37 PM, Peter Geoghegan wrote:
> On Mon, Jul 7, 2014 at 12:57 PM, Robert Haas wrote:
>> 5. It's tempting to look at other ways of solving the parallel sort
>> problem that don't need an allocator - perhaps by simply packing all
>> the tuples into a DSM one after the next.
On Mon, Jul 7, 2014 at 8:51 PM, Fujii Masao wrote:
> On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes wrote:
>> On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes wrote:
>>> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund
>>> wrote:
On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
> On Mon, Jun 23
Petr Jelinek writes:
> here is a patch implementing varwidth_bucket (naming is up for
> discussion) function which does binning with variable bucket width.
I didn't see any discussion of the naming question in this thread.
I'd like to propose that it should be just "width_bucket()"; we can
easil
On Sun, Jul 6, 2014 at 4:17 AM, Craig Ringer wrote:
> After someone reported somewhat less than informative errors in bytea
> decoding (http://stackoverflow.com/q/24588866/398670) I thought I'd put
> together a quick patch to improve the errors here.
The first two changes seem fine from here, but
Abhijit Menon-Sen writes:
> I can confirm that it works fine. I have attached here a very slightly
> tweaked version of the patch (removed trailing whitespace, and changed
> some comment text).
> I'm marking this ready for committer.
I don't know enough about XML/XPATH to know if this is a good
Jeevan Chalke writes:
> Can't we remove this else all-together and print extra line unconditionally?
> Also can we remove curly braces in if and else near these code changes ?
> (Attached patch along those lines)
I committed this with slight further rearrangement to create what seems
like better
On Mon, Jul 7, 2014 at 12:57 PM, Robert Haas wrote:
> 5. It's tempting to look at other ways of solving the parallel sort
> problem that don't need an allocator - perhaps by simply packing all
> the tuples into a DSM one after the next. But this is not easy to do,
> or at least it's not easy to d
On Mon, Jul 7, 2014 at 01:44:59PM -0400, Bruce Momjian wrote:
> On Mon, Jul 7, 2014 at 11:24:51AM -0400, Robert Haas wrote:
> > > As far as the reusing of oids, we don't set the oid counter until after
> > > the restore, so any new unmatched toast table would given a very low
> > > oid. Since we
I wrote previously about my efforts to create a new memory allocator
(then called sb_alloc, now renamed to BlockAllocatorContext in my git
branch for consistency with existing identifiers) for PostgreSQL. To
make a long story short, many of the basic concepts behind that patch
still seem sound to
At 2014-07-07 09:48:44 +0200, and...@2ndquadrant.com wrote:
>
> I'd suggest only defining INT64_MODIFIER here and build INT64_FORMAT,
> UINT64_FORMAT ontop, in c.h.
Oh, I see. I'm sorry, I misread your earlier suggestion. Regenerated
patches attached. Is this what you had in mind?
-- Abhijit
diff
On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane wrote:
> I doubt it. The extra code isn't the problem so much, it's the extra
> planning cycles spent trying to make proofs that will usually fail.
> What you propose will create a combinatorial explosion in the number
> of proof paths to be considered.
W
On Thu, Jul 3, 2014 at 1:14 AM, Stephen Frost wrote:
> Alright, apologies for it being a bit later than intended, but here's
> what I've come up with thus far.
>
> -- policies defined at a table scope
> -- allows using the same policy name for different tables
> -- with quals appropriate for each
On Mon, Jul 7, 2014 at 11:24:51AM -0400, Robert Haas wrote:
> > As far as the reusing of oids, we don't set the oid counter until after
> > the restore, so any new unmatched toast table would given a very low
> > oid. Since we restore in oid order, for an oid to be assigned that was
> > used in t
On Fri, Jul 4, 2014 at 11:12:58PM -0400, Bruce Momjian wrote:
> On Fri, Jul 4, 2014 at 12:01:37AM -0400, Bruce Momjian wrote:
> > > The most robust, but not trivial, approach seems to be to prevent toast
> > > table creation if there wasn't a set_next_toast_pg_class_oid(). Then,
> > > after all r
On 2014-07-07 12:06:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
> >> Well, see the comment that explains why the logic is like this now:
>
> > I think we should 'simply' make sequences assign a toplevel xid - then
> > we can get rid of that
David Rowley writes:
> On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane wrote:
>> I poked around to see if we didn't have some code already for that, and
>> soon found that not only do we have such code (equality_ops_are_compatible)
>> but actually almost this entire patch duplicates logic that already e
Tom Lane wrote:
> Also, -1 for adding another log_line_prefix escape. If you're routing
> multiple clusters logging to the same place (which is already a bit
> unlikely IMO), you can put distinguishing strings in log_line_prefix
> already. And it's not like we've got an infinite supply of letter
On Tue, Jul 8, 2014 at 1:06 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
>>> Well, see the comment that explains why the logic is like this now:
>
>> I think we should 'simply' make sequences assign a toplevel xid - then
>> we can get rid of that sp
Andres Freund writes:
> On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
>> Well, see the comment that explains why the logic is like this now:
> I think we should 'simply' make sequences assign a toplevel xid - then
> we can get rid of that special case in RecordTransactionCommit(). And I
> think t
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we should rework RecordTransactionCommit() to only wait for the
> > standby if `markXidCommitted' and not if `wrote_xlog'. There really
> > isn't a reason to make a readonly transaction's commit wait just because
> >
On Fri, Jul 4, 2014 at 11:12 PM, Bruce Momjian wrote:
> On Fri, Jul 4, 2014 at 12:01:37AM -0400, Bruce Momjian wrote:
>> > The most robust, but not trivial, approach seems to be to prevent toast
>> > table creation if there wasn't a set_next_toast_pg_class_oid(). Then,
>> > after all relations ar
Ashutosh Bapat writes:
> Right now, constraint exclusion code looks only at the provided conditions.
> If we want avoid table scan based on constraints in the above example, it
> will need to look at the implied conditions as well. E.g. val2 < 30 AND val
> = val2 => val < 30. Then the constraint e
Andres Freund writes:
> I think we should rework RecordTransactionCommit() to only wait for the
> standby if `markXidCommitted' and not if `wrote_xlog'. There really
> isn't a reason to make a readonly transaction's commit wait just because
> it did some hot pruning.
Well, see the comment that ex
On Fri, Jul 4, 2014 at 10:33 AM, Tom Lane wrote:
> Vik Fearing writes:
>>> You mean that if synchronous_standby_names is an empty it automatically
>>> should be set to cluster_name?
>
>> No, I mean that synchronous_standby_names should look at cluster_name
>> first, and if it's not set then unfor
On Fri, Jul 4, 2014 at 1:15 AM, Dilip kumar wrote:
> In attached patch, I have moved pgpipe, piperead functions to src/port/pipe.c
If we want to consider proceeding with this approach, you should
probably separate this into a refactoring patch that doesn't do
anything but move code around and a f
Hi.
I took a quick look at this patch, more or less because nobody else did.
> Duing last CF, I proposed to match long pathkeys against index columns
> during creating index paths. This worked fine but also it is difficult
> to make sure that all side-effects are eliminated. Finally Tom Lane
> su
On Fri, Jul 4, 2014 at 12:36 AM, Rushabh Lathia
wrote:
> On Fri, Jul 4, 2014 at 7:37 AM, Tom Lane wrote:
>> Tom Dunstan writes:
>> > On 4 July 2014 00:07, Tom Lane wrote:
>> >> It sounds to me like designing this for JDBC's getGeneratedKeys method
>> >> is a mistake. There isn't going to be an
Le lundi 7 juillet 2014 07:58:33 Robert Haas a écrit :
> On Mon, May 26, 2014 at 12:17 PM, Tom Lane wrote:
> > Albe Laurenz writes:
> >> In addition to data type mapping questions (which David already raised)
> >> I have one problem when I think of the Oracle FDW:
> >>
> >> Oracle follows the SQ
On Mon, May 26, 2014 at 12:17 PM, Tom Lane wrote:
> Albe Laurenz writes:
>> In addition to data type mapping questions (which David already raised)
>> I have one problem when I think of the Oracle FDW:
>
>> Oracle follows the SQL standard in folding table names to upper case.
>> So this would nor
On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane wrote:
> David Rowley writes:
> > On 6 July 2014 03:20, Tom Lane wrote:
> >> Just to note that I've started looking at this, and I've detected a
> rather
> >> significant omission: there's no check that the join operator has
> anything
> >> to do with th
On Tue, Jun 24, 2014 at 11:57 AM, Jeff Janes wrote:
> On Mon, Jun 23, 2014 at 6:25 PM, Jeff Janes wrote:
>> On Mon, Jun 23, 2014 at 3:53 PM, Andres Freund
>> wrote:
>>> On 2014-06-23 13:10:34 -0400, Robert Haas wrote:
On Mon, Jun 23, 2014 at 9:10 AM, Kevin Grittner
wrote:
> I wou
Hi MauMau,
Other than my pervious comments, patch looks good to me. Thanks.
Regards,
Muhammad Asif Naeem
On Wed, Feb 26, 2014 at 2:14 AM, Peter Eisentraut wrote:
> You should be able to do this without specifically referencing the names
> "libpq" or "ecpg". Look into the Makefile, if it defi
Hi,
Found two (A and B) issues with latest patch:
A:
-- Set prompts
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=#
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-# abc;
ERROR: relation "abc" does not exist
LINE 4: abc;
^
Thank you for review comments.
>There are still numerous formatting changes required, e.g. spaces around
>"=" and correct formatting of comments. And "git diff --check" still has
>a few whitespace problems. I won't point these out one by one, but maybe
>you should run pgindent
I will do this.
>C
On Mon, Jul 7, 2014 at 4:14 PM, Andres Freund wrote:
> Hi,
>
> On 2014-07-04 22:59:15 +0900, MauMau wrote:
>> My customer reported a strange connection hang problem. He and I couldn't
>> reproduce it. I haven't been able to understand the cause, but I can think
>> of one hypothesis. Could you g
On Fri, Jul 4, 2014 at 7:45 PM, wrote:
>> > Thanks for reviewing the patch!
>> >
>> > I think that this refactoring patch is useful for improving source
>> > code readability and making the future patches simpler, whether we
>> > adopt your patch or not. So, barring any objections, I'm thinking t
On 2014-07-04 18:59:07 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
> >
> > I think we're going to have to redefine the
> > PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in configure.in to
> > define INT64_MODIFIER='"ll/l/I64D"'
>
> I've attached
Hi Haribabu,
Thank you for sharing the patch. I have spent some time to review the
changes. Overall patch looks good to me, make check and manual testing
seems run fine with it. There seems no related doc/sgml changes ?. Patch
added network_smaller() and network_greater() functions but in PG sourc
On Mon, Jun 30, 2014 at 4:45 PM, Abhijit Menon-Sen
wrote:
> At 2014-06-30 16:35:45 +0500, anaeem...@gmail.com wrote:
> >
> > pc1dotnetpk:postgresql asif$ patch -p0 <
> > > ~/core/min_max_support_for_inet_datatypes/inet_agg_v4.patch
> > > can't find file to patch at input line 3
> > > Perhaps you
At 2014-07-07 14:02:15 +0530, amit.khande...@enterprisedb.com wrote:
>
> Other than some minor comments as mentioned below, I don't have any
> more issues, it looks all good.
Thank you. (Updated patch attached.)
-- Abhijit
diff --git a/src/backend/access/nbtree/nbtxlog.c b/src/backend/access/nbtr
On 4 July 2014 19:11, Abhijit Menon-Sen wrote:
> Updated patch attached, thanks.
>
> Amit: what's your conclusion from the review?
>
Other than some minor comments as mentioned below, I don't have any more
issues, it looks all good.
XLogLockBlockRangeForCleanup() function header comments has th
On Sun, 2014-07-06 at 21:11 -0700, Jeff Davis wrote:
> On Wed, 2014-04-16 at 12:50 +0100, Nicholas White wrote:
> > Thanks for the detailed feedback, I'm sorry it took so long to
> > incorporate it. I've attached the latest version of the patch, fixing
> > in particular:
Looking a little more:
*
So what's wrong with the patch?
And what should I change in it for 9.5?
2014-07-07 3:12 GMT+04:00 Greg Stark :
> On Sun, Jul 6, 2014 at 8:40 AM, Sergey Muraviov
> wrote:
> > Is there anyone who can commit the patch?
>
> So what I'm inclined to do here (sigh) is commit it into 9.5 and
> revert i
At 2014-07-02 10:44:23 +0530, a...@2ndquadrant.com wrote:
>
> Miscellaneous
> -
>
> contrib/fastbloat - tool for quickly assessing bloat stats for a table
> Pending review by Jaime.
>
> showing index update time on EXPLAIN
> Pending updated patch by Jaime.
>
> idle_in_transac
At 2014-07-02 10:54:05 +0530, a...@2ndquadrant.com wrote:
>
> Functions
> -
>
> min/max support for inet datatypes
> Pending review by Muhammad Asif Naeem.
No updates.
> Selectivity estimation for inet operators
> Dilip Kumar plans to post a review this week.
Reviewed, and updat
At 2014-07-02 11:09:19 +0530, a...@2ndquadrant.com wrote:
>
> System administration
> -
>
> pg_hibernator
> Nice feature, some discussion, no code reviews. Status not entirely
> clear, but updated patch available.
Now being reviewed by MauMau.
> Monitoring & control
>
At 2014-07-02 11:14:52 +0530, a...@2ndquadrant.com wrote:
>
> Security
>
>
> Row-security based on Updatable security barrier views
> Lots of discussion that I haven't dared to look at properly yet. I
> gather there's still plenty of design-level work needed, and this
> is not
At 2014-07-02 11:21:53 +0530, a...@2ndquadrant.com wrote:
>
> SQL commands
>
>
> Event triggers: object creation support
> Enormous patch, no reviews, no reviewers, but it's known to work
> already. Does anyone want to have a look at this? (I thought it
> was being reviewe
>> Custom Plan API
>> Shigeru Hanada has said he plans to post a design review soon.
>
> Any updates? Should this be moved to the next CF?
>
Now I'm working to revise the patch according to his suggestion;
will be completed within a couple of days.
A few issues needs design-level suggestion fro
Hi,
On 2014-07-04 22:59:15 +0900, MauMau wrote:
> My customer reported a strange connection hang problem. He and I couldn't
> reproduce it. I haven't been able to understand the cause, but I can think
> of one hypothesis. Could you give me your opinions on whether my hypothesis
> is correct, an
At 2014-07-02 11:38:31 +0530, a...@2ndquadrant.com wrote:
>
> Performance
> ---
>
> scalable LWLocks
> Generic atomics implementation
> Both under active discussion.
Work continues on these.
> KNN-GiST with recheck
> Partial sort
> Some earlier discussion, but no conclusions, and
At 2014-07-02 10:36:23 +0530, a...@2ndquadrant.com wrote:
>
> Server features
> ---
>
> Lag & Lead Window Functions Can Ignore Nulls
> Latest patch currently pending review by Jeff and Álvaro. No
> updates so far.
Jeff has posted a review, and is working on the patch further.
63 matches
Mail list logo
