| From: | Greg Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Christian Schröder <cs(at)deriva(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [GENERAL] Performance of full outer join in 8.3 |
| Date: | 2009-04-18 12:39:27 |
| Message-ID: | 4136ffa0904180539p64e3afc5s6ce52a371d2d3387@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Sat, Apr 18, 2009 at 1:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm inclined to think that some sort of fuzzy examination of EXPLAIN
> output (in this example, "are there constant-comparison conditions in
> the relation scans?") might do the job, but I'm not sure how we'd
> go about that.
If we just removed all the costs and other metrics from the explain
plan and verified that the plan structure was the same would you be
happy with that? It would still be work to maintain every time the
planner changed.
I suppose if we had explain-to-a-table then we could run explain and
then run an sql query to verify the specific properties we were
looking for.
A similar thing could be done with xml if we had powerful enough xml
predicates but we have a lot more sql skills in-house than xml.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John DeSoi | 2009-04-18 12:54:11 | Re: Full text search strategy for names |
| Previous Message | Tom Lane | 2009-04-18 12:32:07 | Re: [GENERAL] Performance of full outer join in 8.3 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-04-18 13:29:26 | Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE |
| Previous Message | Tom Lane | 2009-04-18 12:32:07 | Re: [GENERAL] Performance of full outer join in 8.3 |