Saturday, September 6, 2008

[HACKERS] About that CommitFest redirect page ...

So according to
http://wiki.postgresql.org/index.php?title=CommitFest&action=history
there's been rather a lot of confusion about where the CommitFest
redirect page should point when.

I think the problem is that we need two redirect pages: one for "the
place where you should submit a new patch" and one for "the commitfest in
progress". The problem is to choose names that will make it reasonably
obvious which is which.

Another possibility is to convert CommitFest to a plain page with
suitably-explained links leading to the two relevant pages. However,
a redirect would be nicer because you could bookmark it.

Ideas?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
> seems there is something wrong in the unlikely macro (i'm using GCC
> 4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)

> postgres=# select -256::uint1;
> ERROR: uint1 out of range

No, that's just because this is parsed as -(256::uint1)

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [GENERAL] recover in single-user backend fails

"Wouter Sergeyssels" <Wouter@nucleus.be> writes:
> When doing a recover in a single-user backend we get the following
> error:

> $ postgres -D /var/lib/pgsql/data/ test
> PANIC: block 24929 unfound

This looks like it is probably a case of a design problem that was fixed
in 8.2: the WAL replay code wasn't prepared for the case of finding an
update record for a page that was since truncated away (or its table was
dropped entirely).

FWIW, the only exact matches to that message spelling that I can find in
the 8.1 sources are in gistxlog.c, so this problem is evidently
corruption in a GIST index. Dunno if that information is of any help.
But the real problem is that since the recovery is aborting here, no
other corrections from WAL are getting applied, so anything else that
was changed lately is also at risk.

The only recovery strategy that I can think of in 8.1 is to blow away
your WAL with pg_resetxlog, let the database come up in a damaged
condition, and then try to extract data from it. The best bet would be
to try to get a complete pg_dump out of it, and then initdb and reload;
since you don't know exactly what's been corrupted, you should not try
to go back into production without an initdb/reload.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] traduccion documentacion

Me parece muy valido el criterio de Jaime, seria buscar alguien que domine phyton para que nos colabore con la herramienta.

Otro criterio que se me ocurre para tener en cuenta en esta herramienta es, que si por alguna razón ajena a la persona que encontremos para colaborar en el mantenimiento de la herramienta, dicha persona no pueda seguir colaborando, es fácil conseguir otra persona que se encargue de esto si el lenguaje es el actual?, o es mas rápido conseguir alguien que maneje java (jsp), o es más rápido conseguir alguien que maneje php?.

Ahí les dejo mi inquietud.

Un comentario final, si la cosa es enserio para mantener actualizada la traducción de la documentación de postgresql, yo me puedo comprometer a que mi empresa se responsabilice en el mantenimiento de la herramienta, pero tocaría pasarla a java que es lo que mi empresa domina.

No es más por el momento.


2008/9/6 Jaime Casanova <jcasanov@systemguards.com.ec>
2008/9/5 William Diaz Pabón <widipa@gmail.com>:
> Lo otro seria conseguir los fuentes de esa aplicación webtraslator y
> yo podría ayudar a pasarlo a java (jsp) que es lo que manejo
>

el problema no es conseguir los fuentes... sino mantenerlo en el
lenguaje en que esta, no me parece buena idea empezar a moverlo.
primero porque ya funciona y segundo porque la siguiente vez a que
lenguaje lo moveremos? vamos a terminar con una bonita aplicacion
portada a varios lenguaje y que nadie usa

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157



--
Cordialmente.


William Diaz Pabón
Gerente de Tecnología
InfoTech Soluciones Ltda.
Cel: 3173314172 - 3156396316
Tunja - Boyacá - Colombia
http://www.infotechsoluciones.com

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

On Sun, Aug 31, 2008 at 3:35 PM, Ryan Bradetich <rbradetich@gmail.com> wrote:
> Hello all,
>

a few comments.

- i think you have to add some more comments in uint.c file and maybe
a header indicating this is part of the postgresql project or that is
intended to use with postgres or something of the like

- what is uint1? i know int, int2, int4, int8 so i think we should
have uint, uint2, uint4 (maybe uint8?)

> uint-base.tar.bz2 -- The core of the unsigned integer type.

seems there is something wrong in the unlikely macro (i'm using GCC
4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)

postgres=# select -256::uint1;
ERROR: uint1 out of range
STATEMENT: select -256::uint1;
ERROR: uint1 out of range
postgres=# select -255::uint1;
?column?
----------
-255
(1 row)

postgres=# select -2::uint1;
?column?
----------
-2
(1 row)

postgres=# select -5::uint1 + 30::uint1;
?column?
----------
25
(1 row)

> uint-tests.tar.bz2 -- The regression tests.
>

here failed two regression tests but that is because the path

> * Converted build system to use PGXS (more portable).

the Makefile doesn't work here... i have installed postgres 8.3.3 from
ubuntu package and the test env i compile manually (the uint module
tried to install in the ubuntu location while it should in the env
location)

attached a Makefile that fix that

i still have to make some more test...

--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157

Re: [HACKERS] Prototype: In-place upgrade v02

Heikki Linnakangas wrote:
> > 4) This patch contains more topics for decision. First is general if
> > this approach is acceptable.
>
> I don't like the invasiveness of this approach. It's pretty invasive
> already, and ISTM you'll need similar switch-case handling of all data
> types that have changed the internal representation as well.
>
> We've talked about this before, so you'll remember that I favor teh
> approach is to convert the page format, page at a time, when the pages
> are read in. I grant you that there's non-trivial issues with that as
> well, like if the converted data takes more space and don't fit in the
> page anymore.

I 100% agree with Heikki here; having the conversion spill out into the
main backend is very expensive and adds lots of complexity. The only
argument for the Zdenek's conversion spill appoach is that it allows
conversion to happen at a more natural time than when the page is read
in, but frankly I think the conversion needs are going to be pretty
limited and are better done in a localized way at page read-in time.

As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.

> I wonder if we could go with some sort of a hybrid approach? Convert the
> whole page when it's read in, but if it doesn't fit, fall back to
> tricks like loosening the alignment requirements on platforms that can
> handle non-aligned data, or support a special truncated page header,
> without pd_tli and pd_prune_xid fields. Just a thought, not sure how
> feasible those particular tricks are, but something along those lines..
>
> All in all, though. I find it a bit hard to see the big picture. For
> upgrade-in-place, what are all the pieces that we need? To keep this
> concrete, let's focus on PG 8.2 -> PG 8.3 (or are you focusing on PG 8.3
> -> 8.4? That's fine with me as well, but let's pick one) and forget
> about hypothetical changes that might occur in a future version. I can see:
> 1. Handling page layout changes (pd_prune_xid, pd_flags)
> 2. Handling tuple header changes (infomask2, HOT bits, combocid)
> 3. Handling changes in data type representation (packed varlens)
> 4. Toast chunk size
> 5. Catalogs
>
> After putting all those together, how large a patch are we talking
> about, and what's the performance penalty then? How much of all that
> needs to be in core, and how much can live in a pgfoundry project or an
> extra binary in src/bin or contrib? I realize that none of us have a
> crystal ball, and one has to start somewhere, but I feel uneasy
> committing to an approach until we have a full plan.

Yes, another very good point.

I am ready to focus on these issues for 8.4; all this needs to be
fleshed out, perhaps on a wiki. As a starting point, what would be
really nice is to start a wiki that lists all data format changes for
every major release.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[COMMITTERS] pgsql: Adjust psql's new \ef command to present an empty CREATE FUNCTION

Log Message:
-----------
Adjust psql's new \ef command to present an empty CREATE FUNCTION template
for editing if no function name is specified. This seems a much cleaner way
to offer that functionality than the original patch had. In passing,
de-clutter the error displays that are given for a bogus function-name
argument, and standardize on "$function$" as the default delimiter for the
function body. (The original coding would use the shortest possible
dollar-quote delimiter, which seems to create unnecessarily high risk of
later conflicts with the user-modified function body.)

Modified Files:
--------------
pgsql/doc/src/sgml/ref:
psql-ref.sgml (r1.210 -> r1.211)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.210&r2=1.211)
pgsql/src/backend/utils/adt:
ruleutils.c (r1.283 -> r1.284)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/ruleutils.c?r1=1.283&r2=1.284)
pgsql/src/bin/psql:
command.c (r1.194 -> r1.195)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/command.c?r1=1.194&r2=1.195)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [NOVICE] looking to have 7.x behavior on 8.2/8.3

marc+psqlnoob@milestonerdl.com wrote:
> If I invoke postgres with -d5 every interaction gets dumped to the screen.
> 2008-09-05 01:34:44 [4421] DEBUG: ProcessQuery
> 2008-09-05 01:34:44 [4421] DEBUG: CommitTransactionCommand
> 2008-09-05 01:34:44 [4421] DEBUG: proc_exit(0)
> 2008-09-05 01:34:44 [4421] DEBUG: shmem_exit(0)
> 2008-09-05 01:34:44 [4421] DEBUG: exit(0)
> 2008-09-05 01:34:44 [4364] DEBUG: reaping dead processes
> 2008-09-05 01:34:44 [4364] DEBUG: child process (PID 4421) exited with exit code 0
> 2008-09-05 01:34:44 [4429] LOG: connection received: host=[local] port=
> 2008-09-05 01:34:44 [4364] DEBUG: forked new backend, pid=4429 socket=9
> 2008-09-05 01:34:44 [4429] LOG: connection authorized: user=postgres database=template1
> 2008-09-05 01:34:44 [4429] DEBUG: /usr/lib/postgresql/bin/postmaster child[4429]: starting with (
> 2008-09-05 01:34:44 [4429] DEBUG: postgres
> 2008-09-05 01:34:44 [4429] DEBUG: -d5
> 2008-09-05 01:34:44 [4429] DEBUG: -v196608
> 2008-09-05 01:34:44 [4429] DEBUG: -p
> 2008-09-05 01:34:44 [4429] DEBUG: template1
> 2008-09-05 01:34:44 [4429] DEBUG: )
> 2008-09-05 01:34:44 [4429] DEBUG: InitPostgres
>
>
> How do I get that behavior on 8.2.x/8.3.x ?

client_min_messsage or log_min_messages will do this if set to
debug5.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

Re: [HACKERS] Need more reviewers!

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Thu, Sep 04, 2008 at 09:54:02PM +0100, Simon Riggs wrote:
> > * coding review - does it follow standard code guidelines? Are there
> > portability issues? Will it work on Windows/BSD etc? Are there
> > sufficient comments?
> >
> > * code review - does it do what it says, correctly?
>
> Just one thing though, I picked a random patch and started reading.
> However, the commitfest page doesn't link to anywhere that actually
> describes *what* the patch is trying to do. Many patches do have the
> design and the patch in one page, but some don't.
>
> I suppose what happens is the original patch comes with design and
> later a newer version is posted with just changes. The commitfest page
> points to the latter, losing former in the archive somewhere.

Yep, that is a problem; the previous emails about the patch and comments
are very valuable for reviewers.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] to_date() validation

On Fri, Aug 29, 2008 at 7:39 PM, Brendan Jurd <direvus@gmail.com> wrote:
> Hi all,
>
> Well, it's been a long time coming, but I've finally got a patch to
> improve the error handling of to_date() and to_timestamp(), as
> previously discussed on -hackers. [1][2]

BTW -patches is obsolete just submit pathces to -hackers.

Im just following this:
http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.

Submission review: Everything looks good. Tests seem reasonable patch
applies etc.

Usability review: I think both linked threads in the parent mail give
sufficient justification.

Feature test: Everything seems to work as advertised. However before
via sscanf() most limited the max length of the input. Before they
were just silently ignored now they get added to the result:

patched:
# SELECT to_timestamp('11111', 'HHMM');
to_timestamp
------------------------------
0009-03-19 11:00:00-06:59:56

8.3.3:
# SELECT to_timestamp('11111', 'HHMM');
to_timestamp
---------------------------
0001-11-01 11:00:00-07 BC

Performance review: simple pgbench of to_timestamp did not show any
noticeable differences

Coding review: seemed fine to me, code matched surrounding style,
comments made sense etc

Code review: one minor nit
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
***************
*** 781,787 **** static const KeyWord DCH_keywords[] = {
{"y", 1, DCH_Y, TRUE, FROM_CHAR_DATE_GREGORIAN},

/* last */
! {NULL, 0, 0, 0}
};

/* ----------
--- 781,787 ----
{"y", 1, DCH_Y, TRUE, FROM_CHAR_DATE_GREGORIAN},

/* last */
! {NULL, 0, 0, 0, 0}
};

/* ----------
***************

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] still alive?

Abhijit Menon-Sen wrote:
> I thought -patches was supposed to die. What happened?

I was wondering the same thing. Peter?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PERFORM] SAN and full_page_writes

Nikolas Everett wrote:
> I seem to have answered my own question. I'm sending the answer to the list
> in case someone else has the same question one day.
>
> According to the NetApp documentation, it does protect me from partial page
> writes. Thus, full_page_writes = off.

Just for clarification, the NetApp must guarantee that the entire 8k
gets to disk, not just one of the 512-byte blocks that disks use
internally.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [HACKERS] reducing statistics write overhead

Too frequent read protection is already handled in the patch but these comments might lead it into new directions. Current implementation had this same limit that file was written no more than once per 500 ms.

On Sat, Sep 6, 2008 at 9:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".

> Things that come to mind:

> - autovacuum could use a more frequent stats update in certain cases

BTW, we could implement that by, instead of having a global tunable,
including a field in the request message saying how stale an existing
file is acceptable for this requestor.  500ms might be the standard
value but autovac could use a smaller number.

                       regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] "\ef " in psql

At 2008-09-06 14:58:25 -0400, tgl@sss.pgh.pa.us wrote:
>
> I wrote:
> > ... define
> > \ef with no argument as being the command that presents an empty
> > CREATE FUNCTION command template to fill in.
>
> No complaints? I'll go make that happen.

No complaints, it sounds fine to me.

> What about the general issue that neither \e nor \ef leave you with a
> presentation of what's in the query buffer?

I don't know how that can be fixed; but I agree with Brendan that it's
behaviour that people are used to, and that it can be left alone for
now.

-- ams

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [NOVICE] telnet examples

Jason Dusek wrote:
> For the time being, I've basically given up on this -- we're
> using netcat hooked to `psql` and allowing the client to use
> raw SQL. This is obviously not a long term solution, but it
> does allow us to proceed in the short term.

Good solution. The API for sending queries and returning results is
just too complex to ever emulate in telnet directly.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

Re: [GENERAL] Subqueries in Check() -- Still Intentionally Omitted?

Tom Lane wrote:
> "Richard Broersma" <richard.broersma@gmail.com> writes:
> > I am curious if the motivation is still valid for intentionally
> > omitting check sub-queries. (what was the motivation to begin with?)
>
> > Since we can effectively work around this limitation by doing the same
> > thing with a function in a CHECK constraint, why would we want to
> > prevent anyone from using the standard syntax for achieving the same
> > effect?
>
> Because if we supported the standard syntax, we'd also have to support
> the standard semantics; which a function-in-CHECK does *not* give you.
>
> The standard says that the constraint is guaranteed not to be violated,
> which in the worst case means that any time you update the table(s)
> referenced in the subquery, you have to retest the CHECK expression
> at every row of the table having the constraint. Consider for instance
> CREATE TABLE t1 (x int CHECK (x < (SELECT sum(y) FROM t2)));
> If we change some value of t2.y, do all values of t1.x still satisfy
> their constraint?
>
> In some cases, with enough intelligence you could optimize this into
> something fast enough to be usable; but it's a research problem.
> (The cases that I can see how to optimize are pretty much equivalent to
> plain foreign key constraints, anyway.)

Is this a TODO? I assume it is not.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] rpm install not recognized by yum.

Hi,

On Wed, 2008-09-03 at 11:24 -0400, slamp slamp wrote:

> how come? also when i performed yum clean all i get
> the message "Repository pgdg82 is listed more than once in the
> configuration". although i only see one declaration of pgdg82, the
> other is pgdg82-source. Anyone have this issue?

Please check /etc/yum.conf file.

We have 8.2 + RHEL 5 on many servers, and we don't have this issue.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [PATCHES] hash index improving v3

"Alex Hunsaker" <badalex@gmail.com> writes:
> On Fri, Sep 5, 2008 at 2:21 PM, Alex Hunsaker <badalex@gmail.com> wrote:
>> Ok now that I made it so it actually *test* collisions, with the patch
>> it always returns all rows that matched the hashed "key".

> And here is the fix, we just forget to set the recheck flag for bitmap scans.

For the convenience of anyone intending to test, here is an updated
patch against CVS HEAD that incorporates Alex's fix.

regards, tom lane

Re: [HACKERS] [PATCH] "\ef " in psql

I wrote:
> ... define
> \ef with no argument as being the command that presents an empty CREATE
> FUNCTION command template to fill in.

No complaints? I'll go make that happen.

What about the general issue that neither \e nor \ef leave you with a
presentation of what's in the query buffer? I haven't studied readline
enough to know if that's fixable.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] storing repeating dates / events

Em Saturday 06 September 2008 14:34:22 rkmr.em@gmail.com escreveu:
> yes i am trying to build a alerting system where events will repeat
> weekly/monthly/annually
>
> what is the best way to store this kind of information in postgres?

Use timestamps. And model your application with them.

--
Jorge Godoy <jgodoy@gmail.com>

Re: [HACKERS] pg_dump/pg_restore items

Andrew Dunstan <andrew@dunslane.net> writes:
> What is the state of the following items? I'm a little confused about
> whether or not work is being done on them.

> . splitting pg_dump/pg_restore schema dumps into pre-data and post-data
> sections

A patch for that was proposed and rejected in the last fest; I'm not
sure if anyone is trying to bring it up to speed, but it's in the
archives if anyone wants to.

> . parallel pg_restore

I've not heard that anyone has done any work on this.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Fix an oversight in the 8.2 patch that improved mergejoin

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Sat, 2008-09-06 at 13:06 +0100, Gregory Stark wrote:
>> Is that right? The materialize is just doing the same writing that the final
>> pass of the sort would have been doing. Did we discount the costs for sort for
>> that skipping writing that final pass when that was done?

> IIRC the cost of the sort didn't include the final merge, so when we
> avoided the final merge the cost model for the sort became accurate.
> Perhaps we should add something when we don't do that.

> It seems reasonable than an extra node should cost something anyhow, and
> the per tuple cost is the current standard way of indicating that extra
> cost.

Well, the problem with the previous coding was that the costs assigned
to the various nodes simply failed to add up, because the materialize
node injected by create_mergejoin_plan had not been accounted for at all
in the Path costs. It's fair to question whether cost_sort couldn't be
improved to create a more accurate estimate of what's likely to happen
at runtime given recent changes in the sort code --- but that would be a
distinct issue. I'm not entirely sure how to give cost_sort enough
context info, anyway.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] hash index improving v3

"Alex Hunsaker" <badalex@gmail.com> writes:
> - tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, false);
> + tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, true);

Hah, I bet that explains Jonah's complaint that recheck didn't seem to
be happening in his tests. Nice catch.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".

> Things that come to mind:

> - autovacuum could use a more frequent stats update in certain cases

BTW, we could implement that by, instead of having a global tunable,
including a field in the request message saying how stale an existing
file is acceptable for this requestor. 500ms might be the standard
value but autovac could use a smaller number.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Alvaro, Es obvio que lo fundamental es la traduccion del manual de
postgresql, el resto son tareas pendientes que en el transcurso del
tiempo se tendran que hacer, y segun la capacidad con que se cuente
para abordar ese trabajo, no sobra mencionar esa necesidad.
--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] reducing statistics write overhead

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".

Hmm, I was thinking of delaying both the write and the reply signal
until 500ms had elapsed. But the above behavior would certainly be
easier to implement, and would probably be good enough (TM).

> - Maybe we oughta have separate files, one for each database? That way
> we'd reduce unnecessary I/O traffic for both the reader and the writer.

The signaling would become way too complex, I think. Also what do you
do about shared tables?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Jenaro Centeno Gómez escribió:

> Alvaro,
>
> Te pregunto por ser de las personas con mas experiencias en la lista.
>
> ¿ Que otros lenguajes están avanzados en traducción ?

FR, DE, JA

> Y de ser así,
>
> ¿ Conoces la metodología que han utilizado ?

Han traducido los SGMLs directamente.

Una cosa que sería buena es enfocarse en un proyecto, sin irse demasiado
por las ramas. ¿Queremos traducir la documentación? OK, excelente,
adelante. Por favor no comprometamos al mismo tiempo la traducción del
wiki, del sitio web, y de los videos de Youtube en que aparezca un gordo
con traje de sumo. El que mucho abarca, se lo lleva la corriente; o
algo así.

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [HACKERS] reducing statistics write overhead

Tom Lane escribió:

> (In fact, maybe this patch ought to include some sort of maximum update
> rate tunable? The worst case behavior could actually be WORSE than now.)

Some sort of "if stats were requested in the last 500 ms, just tell the
requester to read the existing file".

Things that come to mind:

- autovacuum could use a more frequent stats update in certain cases

- Maybe we oughta have separate files, one for each database? That way
we'd reduce unnecessary I/O traffic for both the reader and the writer.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] reducing statistics write overhead

Simon Riggs <simon@2ndQuadrant.com> writes:
> On Fri, 2008-09-05 at 15:23 -0400, Tom Lane wrote:
>> How necessary is this given the recent fixes to allow the stats file to
>> be kept on a ramdisk?

> I would prefer this approach and back-out the other change.

Even if we get on-demand done, I wouldn't see it as a reason to back out
the statfile relocation work. In an environment where the stats are
demanded frequently, you could still need that for performance.

(In fact, maybe this patch ought to include some sort of maximum update
rate tunable? The worst case behavior could actually be WORSE than now.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] RE: [pgsql-es-ayuda] Manual de instalación OT

--- El jue 4-sep-08, Edwin Quijada <listas_quijada@hotmail.com> escribió:

> De: Edwin Quijada <listas_quijada@hotmail.com>
> Asunto: RE: [pgsql-es-ayuda] Manual de instalación
> A: hermeszambra@yahoo.com, pgsql-es-ayuda@postgresql.org
> Fecha: jueves, 4 septiembre, 2008, 7:51 pm
> Gabriel, no se que es pelotudo, gracias a Dios, pero es una
> forma de reirnos un poco. Me gusto, lo de traducirlo. :P
>
> *-------------------------------------------------------*
> *-Edwin Quijada
> *-Developer DataBase
> *-JQ Microsistemas
> *-809-849-8087
>

Solo te aclaro lo de pelotudo, si puedo, pelotudo es algo
bobo y sin sentido, en el rio de la plata, boludo y pelotudo son
sinomimos de algo asi, bobo, sin sentido, desganado.


Ahora parece ser que soy defensor de newbies y me definieron Trolls,
me parece que fui muy respetuoso y no quise causar ruido en la lista.

Solamente pienso que instalar postgresql en windows es facil, y las
complicaciones no vienen por el lado de postgresql, si no por algunos
temitas de windows y me dispuse a contestar en privado para no generar
ruido.

A vos y a Jaime los conozco dando excelentes aportes y por eso puse que
me extrañaba esa actitud.

A Jenaro, no lo conozco asi que ni pienso contestarle.

Un abrazo.

____________________________________________________________________________________
Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
--
TIP 8: explain analyze es tu amigo

Re: [GENERAL] Can I truncate statements in the log?

Howard Cole wrote:
> As part of my log configuration, I log statements that take over 3
> seconds. I find this very useful for optimising tables etc. The problem
> is that it produces verbatim some very large statements which can create
> huge log entries, which are probably responsible themselves for slowing
> the system down. The problem tend to be insert statements for binary
> objects - which can be Megabytes long.
>
> Is it possible to stop logging these excessive insert statements
> somehow, or restricting the log of statements to select, delete etc and
> ignore inserts.

No, sorry.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] storing repeating dates / events

On Sat, Sep 6, 2008 at 10:32 AM, Jorge Godoy <jgodoy@gmail.com> wrote:
Em Saturday 06 September 2008 14:12:49 rkmr.em@gmail.com escreveu:
> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?
Along with the timestamp store a boolean that indicates if the event should
consider the year or not.

But you might surely design it better, specially for things that repeat on
intervals other than yearly.
yes i am trying to build a alerting system where events will repeat
weekly/monthly/annually

what is the best way to store this kind of information in postgres?
thanks

Re: [GENERAL] storing repeating dates / events

On Sat, Sep 6, 2008 at 10:21 AM, brian <brian@zijn-digital.com> wrote:
rkmr.em@gmail.com wrote:
Hi
I want to store dates / events for example birthdays (or may 5th) that
repeats every year..
what is the best way to do in postgres?
if i use timestamp it is going to be use the current year.. how do i do
this?
A timestamp includes the year so there shouldn't be any problem. Although, i can't say i'm sure what you think might be the problem. Perhaps you should clarify what it is you want to store, as well as your concerns.

if it includes the year, how do i query  out and find birthdays for this this year? like if i had a table with column

user text,
dob timestamp without timezone,

can you tell me what the query will be to find todays birthday?

Re: [GENERAL] storing repeating dates / events

Em Saturday 06 September 2008 14:12:49 rkmr.em@gmail.com escreveu:
> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?

Along with the timestamp store a boolean that indicates if the event should
consider the year or not.

But you might surely design it better, specially for things that repeat on
intervals other than yearly.

--
Jorge Godoy <jgodoy@gmail.com>

Re: [GENERAL] storing repeating dates / events

rkmr.em@gmail.com wrote:
> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?
>

A timestamp includes the year so there shouldn't be any problem.
Although, i can't say i'm sure what you think might be the problem.
Perhaps you should clarify what it is you want to store, as well as your
concerns.

b

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] storing repeating dates / events

Hi
I want to store dates / events for example birthdays (or may 5th) that repeats every year..
what is the best way to do in postgres?
if i use timestamp it is going to be use the current year.. how do i do this?

Re: [HACKERS] Synchronous Log Shipping Replication

On Fri, 2008-09-05 at 23:21 +0900, Fujii Masao wrote:

> Pavan re-designed the sync replication based on the prototype
> and I posted that design doc on wiki. Please check it if you
> are interested in it.
> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects

It's good to see the detailed design, many thanks.

I will begin looking at technical details next week.

> This design is too huge. In order to enhance the extensibility
> of postgres, I'd like to divide the sync replication into
> minimum hooks and some plugins and to develop it, respectively.
> Plugins for the sync replication plan to be available at the
> time of 8.4 release.

What is Core's commentary on this plan?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Problema SET DATESTYLE TO EUROPEAN

On Sat, Sep 6, 2008 at 11:47 AM, Clemente López Giner
<clemenlg@gmail.com> wrote:
> Hola,
> Tengo un problemilla con las fechas de postgresql en un servidor. Tengo que
> decir que en los dos pcs que tengo, cuando cambio el formato de fecha de
> postgresql no hay problema, pero hay un servidor, que es el que realmente
> importa, en el cual no puedo cambiar el formato de fecha.
> Si me conecto a la base de datos, y pongo la fecha en europeo:
> SET DATESTYLE TO EUROPEAN, SQL;
> SET
> y lo muestro:
> show datestyle ;
> DateStyle
> -----------
> SQL, DMY
> (1 fila)
> Pero si desconecto y vuelvo a conectar a la base de datos...
> show datestyle ;
> DateStyle
> -----------
> ISO, MDY
> (1 fila)
> Parece que cambia el formato a europeo, pero no, no lo hace.

Y esta correcto, lo que no has comprendido es que el cualquier SET que
hagas dentro de la sesión solo sirve y 'vive' en ella.

> Necesito que esté en europeo, puesto que las consultad que hago, siempre
> trato los datos de las fechas con el formato europeo.

Para hacerlo permanente puedes/debes establecer en el archivo
postgresq.conf, sección Locale and Formatting en la opción:

datestyle = 'iso, mdy'

Suponiendo que estas con 8.3.x, dale una leída a la documentación (si
es otra fíjate en la respectiva):

1. http://www.postgresql.org/docs/8.3/static/runtime-config-client.html#GUC-DATESTYLE
2. http://www.postgresql.org/docs/8.3/static/datatype-datetime.html

En especial a la sección: 8.5.2. Date/Time Output.

Saludos y abrazos...

Marco Antonio Frias Butrón
Slackware Linux User
Linux Registered User #356229

--
Sería absurdo que nosotros, que somos finitos, tratásemos de
determinar las cosas infinitas. -- Descartes.
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

[GENERAL] PostgreSQL SSL problem

Hi Team,

I have problems to setup SSL for PostgreSQL server. I did all the steps
which described in the documentation (17.8. Secure TCP/IP Connections
with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
me: "could not start server". And nothing in the logs (I enabled all of
them). I googled around but did not find much.

After I disable SSL option in postgresql.conf the server is starting
successfully.

I have all certificates with proper CA signature, rest of applications
(Postfix, Apache, etc.) work with this certificates very well. I am
using OpenSSL from ports.

Please, advise.

My spec:

FreeBSD 7.0-RELEASE-p3 amd64

PostgreSQL 8.3.3 (installed from ports):

WITH_NLS=true
WITHOUT_PAM=true
WITHOUT_LDAP=true
WITHOUT_MIT_KRB5=true
WITHOUT_HEIMDAL_KRB5=true
WITHOUT_OPTIMIZED_CFLAGS=true
WITH_XML=true
WITHOUT_TZDATA=true
WITHOUT_DEBUG=true
WITH_ICU=true
WITH_INTDATE=true

$ pg_config
BINDIR = /usr/local/bin
DOCDIR = /usr/local/share/doc/postgresql
INCLUDEDIR = /usr/local/include
PKGINCLUDEDIR = /usr/local/include/postgresql
INCLUDEDIR-SERVER = /usr/local/include/postgresql/server
LIBDIR = /usr/local/lib
PKGLIBDIR = /usr/local/lib/postgresql
LOCALEDIR = /usr/local/share/locale
MANDIR = /usr/local/man
SHAREDIR = /usr/local/share/postgresql
SYSCONFDIR = /usr/local/etc/postgresql
PGXS = /usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--with-libraries=/usr/local/lib'
'--with-includes=/usr/local/include' '--enable-thread-safety'
'--with-docdir=/usr/local/share/doc/postgresql' '--with-openssl'
'--with-system-tzdata=/usr/share/zoneinfo' '--enable-integer-datetimes'
'--enable-nls' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd7.0' 'CC=cc'
'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'LDFLAGS= -pthread
-rpath=/usr/local/lib' 'build_alias=amd64-portbld-freebsd7.0'
CC = cc
CPPFLAGS = -I/usr/local/include
CFLAGS = -O2 -fno-strict-aliasing -pipe -Wall -Wmissing-prototypes
-Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -fwrapv
CFLAGS_SL = -fPIC -DPIC
LDFLAGS = -pthread -rpath=/usr/local/lib -L/usr/local/lib
-Wl,-R'/usr/local/lib'
LDFLAGS_SL =
LIBS = -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm
VERSION = PostgreSQL 8.3.3

Thanks,
Andriy

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[BUGS] BUG #4406: silent install error

The following bug has been logged online:

Bug reference: 4406
Logged by: Mike Gagnon
Email address: mike.gagnon@bellnet.ca
PostgreSQL version: 8.3.1
Operating system: Windows XP
Description: silent install error
Details:

Hi,

When I try to do a silent install, I have created the user and password in
windows before trying this:

MSIEXEC /i "postgresql-8.3-int.msi" /qb /log "c:\logfile.txt"
ADDLOCAL="server,nls,psql,pgadmin,includefiles,libfiles,binfiles"
INTERNALLAUNCH=1 DOSERVICE=1 CREATESERVICEUSER=0 DOINITDB=1
SERVICEDOMAIN="<ComputerName>" SERVICEACCOUNT="postgres"
SERVICEPASSWORD="randompass1" SERVICENAME="PostgreSQL Database Server 8.3"
SUPERUSER="postgres" SUPERPASSWORD="postgrespw" LOCALE=C ENCODING=SQL_ASCII
LISTENPORT=5432 PERMITREMOTE=1 PL_PGSQL=1 PL_PERL=1 PL_PERLU=1 PL_TCL=0
PL_TCLU=0 PL_PYTHONU=0 BASEDIR="c:\mydir\PostgreSQL\8.3"

I then get the following error:
"User account ¡¡¡¡¡¡¡s¡¡¡¡\¡¡¡¡¡W does not exist"

It's as if the installer doesn't pick up the correct username I'm giving
it...

Is there any way around this?

Many thanks,
Mike

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[GENERAL] Efficient processing of staging data

Dear,

I'm looking for an efficient way to process data that I have stored in a
staging table. This is syslog output, so it consists of text, where I
need regexes to filter it out. The data will be split into several/a lot
of tables.

I currently have a set of queries that
* read from staging and insert into destination table.
* delete from staging (using destination table).
This requires 2 scans over the tables and the index operations (which
pay of here). I do the processing incrementally, in order to keep run
time under control. But for only 4 filters this will take around 6 to 30
minutes.

My later idea was to do a (incremental) table scan on the staging table
and have a function do the processing of the row. The function will then
either:
* decide to do nothing
* decide to insert the (transformed) row into the destination table and
delete it from the staging table.

An obvious extension would be to put this processing in the INSERT
trigger of the staging table, saving the I/O's requires for an insert
and delete from the staging table. I like to do this afterwards for the
moment.

What are the recommended methods and helpful implementation hints to get
it working optimally? I.e. would my method work or are there any better
solutions possible?

How can I write the filtering functions in such a manner that I can
later transform the solution in a trigger based one?

Regards,

- Joris Dobbelsteen


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] reducing statistics write overhead

On Fri, 2008-09-05 at 15:23 -0400, Tom Lane wrote:

> How necessary is this given the recent fixes to allow the stats file to
> be kept on a ramdisk?

I would prefer this approach and back-out the other change.

On-demand is cheaper and easier to use.

> > Attached is a WIP patch, which basically implements this:
>
> This patch breaks deadlock checking and statement_timeout, because
> backends already use SIGALRM. You can't just take over that signal.
> It's possible that you could get things to work by treating this as an
> additional reason for SIGALRM, but that code is unreasonably complex
> already. I'd suggest finding some other way.

There are other ways already in use in backend, so just use those.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Problema SET DATESTYLE TO EUROPEAN

Hola,
Tengo un problemilla con las fechas de postgresql en un servidor. Tengo que decir que en los dos pcs que tengo, cuando cambio el formato de fecha de postgresql no hay problema, pero hay un servidor, que es el que realmente importa, en el cual no puedo cambiar el formato de fecha.
Si me conecto a la base de datos, y pongo la fecha en europeo:
SET DATESTYLE TO EUROPEAN, SQL;
SET
y lo muestro:
show datestyle ;
DateStyle
-----------
SQL, DMY
(1 fila)
Pero si desconecto y vuelvo a conectar a la base de datos...
show datestyle ;
DateStyle
-----------
ISO, MDY
(1 fila)
Parece que cambia el formato a europeo, pero no, no lo hace.



Necesito que esté en europeo, puesto que las consultad que hago, siempre trato los datos de las fechas con el formato europeo.

¿Alguien sabe porque en el servidor comentado tengo problemas, y en cambio en mis dos pcs no? La instalación en todos ellos es la que trae por defecto debian...

Muchas Gracias

Fwd: [pgsql-es-ayuda] Sobre NpgSql y C#


Hola Grover,

En la página de descargas [1] del proyecto Npgsql encuentras varios archivos para descargar, observa los que tienen "ms" (por ejemplo: Npgsql1.0-bin-ms1.1.zip). Los que traen "ms" incluyen la librería Mono.Security que debes registrar también.


Pdta: Te recomiendo el IDE SharpDevelop [2] para desarrollar en .NET.

Saludos.


Germán Carrillo


-----------------
[1] http://pgfoundry.org/frs/?group_id=1000140
[2] http://sharpdevelop.net/OpenSource/SD/

El 5 de septiembre de 2008 20:10, Grover Navia <grover8navia@yahoo.es> escribió:

Hola listeros
 
Estoy programando con Windows forms en C#.Net 2005, y como gestor de base de datos PostGreSql 7.X; navegando en el Internet encontre NpgSql el acceso a mi bas ede datos de posgresql; baje 3 archivos de NpgSql (Npgsql.dll, Npgsql.dll.mdb, Npgsql.xml), he registrado el archivo Npgsql en mi maquina en la cual estoy programando (SO. Win XP),  despues de agregar el componente a mi cuadro de herramientas; pero al momento de tratar de pegar a mi aplicaionel componente "Npgsqlconnection" me sale un mensaje de error que dice que no encontro el archivo "Mono.Security, Version = 1.0.500, Culture = Neutral ..........."
 
De los 3 archivos mencionados solo he registrado el Npgsql.dll
 
Alguien podria decirme que otro procedimiento adicional debria realizar para que me funione ...?
 
de ante mano las mil gracias por su tiempo y predisposición ...
 
Saludos
Grover Navia

Re: Fwd: [HACKERS] [Patch Review] TRUNCATE Permission

Hello Robert,

On Fri, Sep 5, 2008 at 8:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Updated patch attached, based on comments from Ryan Bradetich and Tom
> Lane, and sync'd to latest CVS version.

Thanks for the update. I am out of town until tomorrow evening.
I will re-review this patch when I get back if it has not been
committed by then.

- Ryan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [COMMITTERS] pgsql: Fix an oversight in the 8.2 patch that improved mergejoin

On Sat, 2008-09-06 at 13:06 +0100, Gregory Stark wrote:
> tgl@postgresql.org (Tom Lane) writes:
>
> > (The materialize protects the sort from having to support mark/restore,
> > allowing it to do its final merge pass on-the-fly.) We neglected to teach
> > cost_mergejoin about that hack, so it was failing to include the
> > materialize's costs in the estimated cost of the mergejoin.
>
> Is that right? The materialize is just doing the same writing that the final
> pass of the sort would have been doing. Did we discount the costs for sort for
> that skipping writing that final pass when that was done?

IIRC the cost of the sort didn't include the final merge, so when we
avoided the final merge the cost model for the sort became accurate.
Perhaps we should add something when we don't do that.

It seems reasonable than an extra node should cost something anyhow, and
the per tuple cost is the current standard way of indicating that extra
cost.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Moises Galan escribió:
> Hola Javier,
>
> Rta 1:
>
> Yo planteo que el PSDP-es es un equipo, ese equipo tiene diferentes
> tareas que cumplir, una de esas es la traduccion, existen otras tareas
> que tambien se enmarcan dentro del proceso de traduccion o permiten
> llegar al proceso de traduccion, una de esas tareas es la recopilacion
> de material a traducir.
> por lo que solo el equipo alfa realiza traducciones, el equipo beta
> recopila material.
>
> Mesa de coordinacion: es un organo de direccion y coordinacion como su
> nombre lo indica, del PSDP-ES. alli se revisa el avance de la
> traduccion,y se aprueba la traduccion final.
>
> Revisor: Persona que tiene facultades para modificar el trabajo de un
> traductor,por su destreza en el manejo del idioma ingles,
> rechazarlo,aceptarlo o darle sugerencias para que presente una mejor
> traduccion de un texto. tambien se trabaja con la modalidad de
> calificacion de la traduccion.tiene derechos para escribir en cvs
> central.
>
> a) Equipo Alfa: compuesto por traductores y un lider de proyecto
>
> b)Equipo Beta: compuesto por miembros del proyecto, para la
> recopilacion de material, no tienen facultades de revisores, El lider
> del equipo alfa participa de la mesa de coordinacion, no como revisor
> ,sino como responsable por las funciones asignadas.
>
> 2) Rta: OK contamos contigo.
>
> 3).Rta Si, presentaciones o tambien llamadas exposiciones,charlas,
> congresos,conferencias,papers, ver pg Conf 2008.tutoriales, How to.
>
> 4. OK, el ciclo vendria a ser el siguiente,
>
> a)Se define la herramientas a utilizar para la traduccion, ya sea el
> framework o el cvs, o git. (!!hay que poner una fecha limite a
> esto!!).
>
> b). El equipo alfa con base en la propuesta de la lista sobre traducir
> lo mas solicitado por la comunidad ( material para los newbies),
> comienza la traduccion de las secciones, partes y capitulos acordados
> y propuestos en mi pasado mensaje.
>
> c). Al interior del Equipo Alfa los miembros del equipo determinan
> como se distribuyen los capitulos,partes y secciones encomandados por
> la mesa coordinadora.se recomienda repartirlos de una forma equitativa
> de tal manera que un traductor no tenga mas carga de trabajo que
> otro,cuando una seccion,parte o capitulo comprenda una extension muy
> grande igualmente se buscara el equilibrio de trabajo entre los
> traductores del equipo.
>
> d). El equipo de traduccion alfa solo entregara al cvs del PSDP-es, el
> material asignado traducido completamente en archivos ¿¿po?? y sgml o
> xml, (esto esta por definir dependiendo de que herramienta
> utilicemos). pero me imagino que lo importante es entregar un archivo
> fuente traducido.
>
> e) Finalizada la traduccion de el material asignado, es remitida al
> cvs del psdp-es donde los revisores toman la traduccion la revisan y
> emiten su validacion o no. si es positiva pasa a ser parte del
> material final para llevar al cvs central. Si es negatiga o necesita
> cambios se rechaza y se remite al autor para que haga los cambios
> necesarios.
>
> Esto es una definicion del ciclo ha grandes rasgos, ya que podria
> variar si utilizamos el framework o si utilizamos git o cvs, pero en
> esencia creo que se aplica a las tres posibles herramientas, es lo que
> sugiero que se aplique.
>
> Por cierto me resulta algo inquietante, saber que no todos han
> aportado su opinion acerca de mi ultimo mensaje, ¿estoy reinventado la
> rueda? ¿No estoy siendo muy pretensioso con todo esto?, creo que
> estamos creando comunidad, es decir subir el segundo peldaño. se
> requiere mucho trabajo para eso.
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>
>
>

Alvaro,

Te pregunto por ser de las personas con mas experiencias en la lista.

¿ Que otros lenguajes están avanzados en traducción ?

Y de ser así,

¿ Conoces la metodología que han utilizado ?

Para no reinventar la rueda.

Saludos.


--
-------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez

Al-Día se renueva con la Mejora Continua
Departamento de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Tel. 01 474 741 9200
Ext. 9280
www.aldia.com.mx

--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Hola Javier,

Rta 1:

Yo planteo que el PSDP-es es un equipo, ese equipo tiene diferentes
tareas que cumplir, una de esas es la traduccion, existen otras tareas
que tambien se enmarcan dentro del proceso de traduccion o permiten
llegar al proceso de traduccion, una de esas tareas es la recopilacion
de material a traducir.
por lo que solo el equipo alfa realiza traducciones, el equipo beta
recopila material.

Mesa de coordinacion: es un organo de direccion y coordinacion como su
nombre lo indica, del PSDP-ES. alli se revisa el avance de la
traduccion,y se aprueba la traduccion final.

Revisor: Persona que tiene facultades para modificar el trabajo de un
traductor,por su destreza en el manejo del idioma ingles,
rechazarlo,aceptarlo o darle sugerencias para que presente una mejor
traduccion de un texto. tambien se trabaja con la modalidad de
calificacion de la traduccion.tiene derechos para escribir en cvs
central.

a) Equipo Alfa: compuesto por traductores y un lider de proyecto

b)Equipo Beta: compuesto por miembros del proyecto, para la
recopilacion de material, no tienen facultades de revisores, El lider
del equipo alfa participa de la mesa de coordinacion, no como revisor
,sino como responsable por las funciones asignadas.

2) Rta: OK contamos contigo.

3).Rta Si, presentaciones o tambien llamadas exposiciones,charlas,
congresos,conferencias,papers, ver pg Conf 2008.tutoriales, How to.

4. OK, el ciclo vendria a ser el siguiente,

a)Se define la herramientas a utilizar para la traduccion, ya sea el
framework o el cvs, o git. (!!hay que poner una fecha limite a
esto!!).

b). El equipo alfa con base en la propuesta de la lista sobre traducir
lo mas solicitado por la comunidad ( material para los newbies),
comienza la traduccion de las secciones, partes y capitulos acordados
y propuestos en mi pasado mensaje.

c). Al interior del Equipo Alfa los miembros del equipo determinan
como se distribuyen los capitulos,partes y secciones encomandados por
la mesa coordinadora.se recomienda repartirlos de una forma equitativa
de tal manera que un traductor no tenga mas carga de trabajo que
otro,cuando una seccion,parte o capitulo comprenda una extension muy
grande igualmente se buscara el equilibrio de trabajo entre los
traductores del equipo.

d). El equipo de traduccion alfa solo entregara al cvs del PSDP-es, el
material asignado traducido completamente en archivos ¿¿po?? y sgml o
xml, (esto esta por definir dependiendo de que herramienta
utilicemos). pero me imagino que lo importante es entregar un archivo
fuente traducido.

e) Finalizada la traduccion de el material asignado, es remitida al
cvs del psdp-es donde los revisores toman la traduccion la revisan y
emiten su validacion o no. si es positiva pasa a ser parte del
material final para llevar al cvs central. Si es negatiga o necesita
cambios se rechaza y se remite al autor para que haga los cambios
necesarios.

Esto es una definicion del ciclo ha grandes rasgos, ya que podria
variar si utilizamos el framework o si utilizamos git o cvs, pero en
esencia creo que se aplica a las tres posibles herramientas, es lo que
sugiero que se aplique.

Por cierto me resulta algo inquietante, saber que no todos han
aportado su opinion acerca de mi ultimo mensaje, ¿estoy reinventado la
rueda? ¿No estoy siendo muy pretensioso con todo esto?, creo que
estamos creando comunidad, es decir subir el segundo peldaño. se
requiere mucho trabajo para eso.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

[HACKERS] pg_dump/pg_restore items

What is the state of the following items? I'm a little confused about
whether or not work is being done on them.

. splitting pg_dump/pg_restore schema dumps into pre-data and post-data
sections
. parallel pg_restore

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[BUGS] BUG #4405: Valid certificate reported as expired

The following bug has been logged online:

Bug reference: 4405
Logged by: Andrej Podzimek
Email address: andrej@podzimek.org
PostgreSQL version: 8.3.3
Operating system: Linux
Description: Valid certificate reported as expired
Details:

Hello,

I thought this was a PgAdmin III issue and reported it on the PgAdmin
mailing list. Only now did I realize that psql has exactly the same
problem.

I have been using psql (and PgAdmin III) with SSL for a couple of months. I
set up certificates for both the server and the client, valid until March
2009. Everything worked fine.

Now the bad news: Both psql and PgAdmin refuse to connect since yesterday,
with this error message:

Error connecting to the server: SSL error: sslv3 alert certificate
expired

This is obviously a nonsense, as both certificates are valid and system
clocks on both computers show correct date and time. I even restarted the
PostgreSQL server, which did not help.

There haven't been any such problems up to now, so what could be wrong? Is
there anything I should try?

Best regards,

Andrej Podzimek

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs