A GUC parameter could govern the data included in this
variant of EXPLAIN, but even that seems unnecessary. This approach will
allow the standard EXPLAIN to evolve in whatever way pleases the humans
without interfering with the machines.
Regards,
Tom Raney
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Tom Raney <[EMAIL PROTECTED]> writes:
Why does the index scan for tenk1 include a path key from
onek.unique2? Is it implying an equivalence there?
bench=# explain select * from tenk1 JOIN onek ON
tenk1.unique2=onek.unique2;
Yes, for an example like that the planner
Tom Lane wrote:
Tom Raney <[EMAIL PROTECTED]> writes:
Why does the planner consider both input variations of each symmetric merge join? The
README says "there is not a lot of difference" between the two options. When
are there any differences?
The righthand side needs
Why does the planner consider both input variations of each symmetric merge join? The
README says "there is not a lot of difference" between the two options. When
are there any differences?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
27;ve been
working on. I haven't had time to revisit this initial work.
-Tom Raney
---
[EMAIL PROTECTED] wrote:
I just posted a patch addressing the TODO item:
"Allow EXPLAIN output to be more easily
nt. I don't want to
modify the planner() entry function parameter list, unless absolutely
necessary.
I currently compile with DEBUG_OPTIMIZER - and that is one option - to
conditionally compile this functionality, but it would be great if this
could run on a lean production system.
-Tom Ra
le with libxml? Are there any lighter weight solutions to
serialize other than libxml?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
s
first EXPLAIN XML concept may have some use. Are there any strong
opinions about the XML hierarchy? Is it enough to simply wrap the text
output from EXPLAIN with XML tags?
-Tom Raney
QUERY PLAN
---
]>
hich could be a good first step for this
project.
Is anyone working on a related project?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ions, overflows occur more
frequently. I spoke with Neil Conway yesterday at the PG conference
here in Portland and he piqued my interest in examining his hash code
more closely to see what he has already done in this area.
-Tom
Cheers,
Ken
On Wed, Oct 17, 2007 at 03:31:58PM -0700,
Kenneth Marshall wrote:
On Tue, Sep 25, 2007 at 03:35:47PM +0100, Gregory Stark wrote:
"Kenneth Marshall" <[EMAIL PROTECTED]> writes:
On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
Using our implementation, build times and index sizes are
compa
, showing a comparative analysis of
btree and hash index builds and describing the benchmark data.
http://web.cecs.pdx.edu/~raneyt/pg/
We are currently cleaning up the patch and will submit it asap.
Regards,
Shreya Bhargava <[EMAIL PROTECTED]>
Tom Raney <[EMAIL PROTECTED]>
Kenneth Ma
12 matches
Mail list logo
