Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

On Wed, Sep 23, 2015 at 7:29 PM, Tom Lane wrote: > Removing that entirely would be quite incorrect, because then you'd be > lying to the parent node about what collation your node outputs. > Yes. I too thought so and thus wanted to fix that code block by considering the

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: > I wrote: > > Hm ... actually, we probably need *both* types of changes if that's > > what we believe the state values mean. > > I too was confused with the state explanations from the code-comments which we have them now.

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Jeevan Chalke writes: > On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: >> After a bit more thinking and experimentation, I propose the attached >> patch. > I had a look over the patch and reviewed it. It is in excellent state to > check-in.

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

On Thu, Sep 24, 2015 at 10:22 PM, Tom Lane wrote: > Jeevan Chalke writes: > > On Wed, Sep 23, 2015 at 10:15 PM, Tom Lane wrote: > >> After a bit more thinking and experimentation, I propose the attached > >> patch. > > > I

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Hi Tom, On Tue, Sep 22, 2015 at 12:31 AM, Tom Lane wrote: > > I think you're blaming the wrong code; RelabelType is handled basically > the same as most other cases. > > It strikes me that this function is really going about things the wrong > way. Rather than trying to

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Jeevan Chalke writes: > On Tue, Sep 22, 2015 at 12:31 AM, Tom Lane wrote: >> It strikes me that this function is really going about things the wrong >> way. Rather than trying to determine the output collation per se, what >> we ought to be

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

I wrote: > After thinking a bit more about the existing special case for non-foreign > Vars, I wonder if what we should do is change these code blocks to look > like > collation = r->resultcollid; > if (collation == InvalidOid) > state =

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

I wrote: > Hm ... actually, we probably need *both* types of changes if that's > what we believe the state values mean. After a bit more thinking and experimentation, I propose the attached patch. regards, tom lane diff --git a/contrib/postgres_fdw/deparse.c

[HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Hi, It is observed that, when we have one remote (huge) table and one local (small) table and a join between them, then 1. If the column type is text, then we push the join qual to the remote server, so that we will have less rows to fetch, and thus execution time is very less. 2. If

Re: [HACKERS] TEXT vs VARCHAR join qual push down diffrence, bug or expected?

Jeevan Chalke writes: > It is observed that, when we have one remote (huge) table and one local > (small) table and a join between them, then > 1. If the column type is text, then we push the join qual to the remote > server, so that we will have less rows to

[HACKERS] text and varchar

Why do we have both the type text and type varchar (without limit)? Couldn't we make one to be an alias for the other? Since it's 2 distinct types there are some strange effects: dennis= SELECT CAST ('123'::varchar AS integer); ERROR: cannot cast type character varying to integer