Hi,
For the ones who couldn't attend to How to Get Your PostgreSQL Patch
Accepted, could someone please make a summary. (Tom? Bruce?)
Thank you.
Regards,
Gevik.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, May 21, 2009 at 12:26:08PM -0400, Tom Lane wrote:
I'd envision it
as an extra column in pg_attribute, and it would work for any column(s).
There's nothing to be gained by restricting it.
Yes, when I said first I meant the only thing that needs to be stored
is the first default value
On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote:
Hi,
For the ones who couldn't attend to How to Get Your PostgreSQL
Patch Accepted, could someone please make a summary. (Tom? Bruce?)
Thank you.
Video will get posted pretty soon after, and expect tweets, blog
posts, etc. :)
please, please, please
David Fetter wrote:
On Fri, May 22, 2009 at 10:39:13AM +0200, Gevik Babakhani wrote:
Hi,
For the ones who couldn't attend to How to Get Your PostgreSQL
Patch Accepted, could someone please make a summary. (Tom? Bruce?)
Thank you.
Video will get posted pretty
Hi,
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that a
SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only shows the number of tuples matching the
qualifier of an SeqScan Node -
...
From 4865950d8bb66ee29cead3ecb17b07812677bfdf Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Fri, 22 May 2009 15:37:13 +0200
Subject: [PATCH] Feature: discarded tuple count display in EXPLAIN ANALYZE
---
src/backend/commands/explain.c|5 +++--
Andres Freund wrote:
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that a
SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only shows the number of tuples matching the
qualifier of
Hi,
On 05/22/2009 03:42 PM, Heikki Linnakangas wrote:
Andres Freund wrote:
When analyzing the plan of a query I often find myself questioning
whether an additional index may be sensible, or if it is sensible that
a SeqScan is used if an index is available.
The current EXPLAIN ANALYZE only
,
--
Tatsuhito Kasahara
kasahara.tatsuh...@oss.ntt.co.jp
diff -cpr Postgresql-CVS-20090522/src/bin/psql/po/ja.po
ja_po_fix/src/bin/psql/po/ja.po
*** Postgresql-CVS-20090522/src/bin/psql/po/ja.po 2009-05-22
18:01:22.0 +0900
--- ja_po_fix/src/bin/psql/po/ja.po 2009-05-23 05:08
On 5/21/09 6:44 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well as as? I believe
that SQL
Josh Berkus wrote:
On 5/21/09 6:44 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
The patch adds the AS keyword to the plpgsql grammar and doesn't
assign an expression parameter to the sql construct if the scalar
follows the AS keyword.
Would it be possible to also support = as well as as? I
As we discussed at pgcon2009 there are some changes/fixes necessary in
information_schema.columns to allow correct work of applications and
services via OLEDB on Windows. Here are some:
1. data_type field contains types names that are not recognized by MS apps.
Code around: rename types on the
Tatsuhito Kasahara wrote:
Hi.
Here is a asmall patch which fixes bin/psql/po/ja.po.
Now, psql returns the incorrect number of rows through ja.po.
(see following)
Thanks. Please submit to pgtranslation through pgfoundry -- see
http://babel.postgresql.org/
--
Alvaro Herrera
Andres Freund and...@anarazel.de writes:
On 05/22/2009 03:42 PM, Heikki Linnakangas wrote:
Isn't the discarded count always equal to (# of rows in table - matched
tuples)? Seems pretty redundant to me.
Not for EXISTS(), LIMIT and similar.
It doesn't really seem useful enough to justify
(quoting more than usual to provide context because this is such an old thread)
On Sat, Oct 4, 2008 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've applied the latest version of the CTE patch. Congratulations on
making that happen!
There are still some loose ends that need to be
On Fri, May 22, 2009 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It doesn't really seem useful enough to justify breaking client-side
code that looks at EXPLAIN output.
Fwiw at least pgadmin I don't think would be confused by this. These
tool authors aren't enamoured of fragile assumptions
Yesterday Jignesh Shah presented his extensive benchmark results comparing
8.4-beta1 with 8.3.7 at PGCon:
http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible for about 80% of that regression.
...
The situation where the stats
On Fri, 2009-05-22 at 16:43 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible
Greg,
* Greg Sabino Mullane (g...@turnstep.com) wrote:
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible for about 80% of that regression.
...
The situation where
Greg Smith gsm...@gregsmith.com writes:
Yesterday Jignesh Shah presented his extensive benchmark results comparing
8.4-beta1 with 8.3.7 at PGCon:
http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
While most cases were dead even or a modest improvement, his dbt-2 results
On Fri, 2009-05-22 at 13:35 -0400, Stephen Frost wrote:
Greg,
dbt-2 is for OLTP, not for DW. Greg Smith's comment was actually that
we shouldn't penalize the OLTP crowd (by raising the value) for the
benefit of the DW crowd (who need it higher than 100 anyway).
I appear to have completely
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible for about 80% of that regression.
Greg Smith gsm...@gregsmith.com writes:
Yesterday Jignesh Shah presented his extensive benchmark results
comparing
8.4-beta1 with 8.3.7 at PGCon:
http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of
While most cases were dead even or a modest improvement, his dbt-2
and...@dunslane.net writes:
Wouldn't he just need to rerun the tests with default_stats_target set to
the old value? I presume he has actually done this already in order to
come to the conclusion he did about the cause of the regression.
Yeah, he did, so we know it's slower that way. But
Joshua D. Drake j...@commandprompt.com writes:
We probably need to test this to get some more data points.
Agreed --- DBT2 is just one data point. We shouldn't assume that it's
definitive.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Greg Sabino Mullane g...@turnstep.com writes:
No, the 10 to 100 was supported by years of people working in the
field who routinely did that adjustment (and 100) and saw great
gains. Also, as the one who originally started the push to 100, my
original goal was to get it over the magic 99 bump,
On Fri, May 22, 2009 2:41 pm, Tom Lane wrote:
Greg Sabino Mullane g...@turnstep.com writes:
No, the 10 to 100 was supported by years of people working in the
field who routinely did that adjustment (and 100) and saw great
gains. Also, as the one who originally started the push to 100, my
On 5/22/09 2:36 PM, Tom Lane wrote:
and...@dunslane.net writes:
Wouldn't he just need to rerun the tests with default_stats_target set to
the old value? I presume he has actually done this already in order to
come to the conclusion he did about the cause of the regression.
Yeah, he did, so we
Hello
2009/5/21 Tom Lane t...@sss.pgh.pa.us:
Steve Prentice prent...@cisco.com writes:
This patch is intended to supplement Pavel's patch for named and mixed
notation support in 8.5. This patch makes it so a plpgsql function can
call another function with the same parameter names using the
When I compile postgresql now I get following message:
../../../src/include/access/reloptions.h, line 45: warning: integer
overflow detected: op
The problem is on the following lines
typedef enum relopt_kind
{
...
RELOPT_KIND_MAX = (1 31)
}
enum is int datatype and 1 31 ==
On Fri, 22 May 2009, Greg Sabino Mullane wrote:
The bump from 10 to 100 was supported by microbenchmarks that suggested it
would be tolerable.
No, the 10 to 100 was supported by years of people working in the field who
routinely did that adjustment (and 100) and saw great gains.
No one is
Attached patch cleanups hash index headers to allow compile hasham for
8.3 version. It helps to improve pg_migrator with capability to migrate
database with hash index without reindexing.
I discussed this patch year ago with Alvaro when we tried to cleanup
include bloating problem. It should
On Thu, May 21, 2009 at 6:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sam Mason s...@samason.me.uk writes:
On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples.
On 22 May 2009, at 16:17, Greg Smith gsm...@gregsmith.com wrote:
On Fri, 22 May 2009, Greg Sabino Mullane wrote:
The bump from 10 to 100 was supported by microbenchmarks that
suggested it
would be tolerable.
No, the 10 to 100 was supported by years of people working in the
field who
Attached patch fixes following sun studio compiler warning:
tsquery_op.c, line 193: warning: syntax error: empty declaration
tsquery_op.c, line 194: warning: syntax error: empty declaration
tsquery_op.c, line 195: warning: syntax error: empty declaration
tsquery_op.c, line 196: warning: syntax
Is there a historical reason why we have a proargtypes and a
proallargtypes?
It seems that proallargtypes is only set when out parameters exist.
Could someone clarify this please?
Regards,
Gevik.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
On 05/22/2009 05:54 PM, Tom Lane wrote:
This sort of ties into the discussions we have periodically about
allowing EXPLAIN to output XML or some other more-machine-friendly
data format. The barrier for adding additional output fields would
be a lot lower in such a format.
So the best
2009/5/23 Gevik Babakhani pg...@xs4all.nl:
Is there a historical reason why we have a proargtypes and a
proallargtypes?
It seems that proallargtypes is only set when out parameters exist.
Could someone clarify this please?
proargtypes is used for fast simple searching function in
39 matches
Mail list logo
