- Forwarded message from Mike Aubury [EMAIL PROTECTED] -
From: Mike Aubury [EMAIL PROTECTED]
To: Michael Meskes [EMAIL PROTECTED]
Subject: PGconn ?
Date: Wed, 30 Jan 2008 19:51:00 +
Any chance of adding this (or something similar) for the next RC?
ecpglib/connect.c :
Michael Meskes [EMAIL PROTECTED] writes:
From: Mike Aubury [EMAIL PROTECTED]
Any chance of adding this (or something similar) for the next RC?
I don't like the idea of adding a feature albeit a very small one to 8.3
at this point in time without even a small discussion. Mike explained to
me
On Fri, Feb 01, 2008 at 12:08:56PM +0100, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm using 8.2.6 and I'm observing a trange behaviour using
offset and limits.
Please post EXPLAIN ANALYZE output so we can see what's actually taking
the time.
Have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm using 8.2.6 and I'm observing a trange behaviour using
offset and limits.
This are the two queries that are puzzling me:
explain SELECT c.id, tsk, lir, nctr, nctn, ncts, rvel,ecp, pvcp,
pvcc,pvcf,pvcl,ldcn,ogtd,sgti
FROM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn van Oosterhout wrote:
On Fri, Feb 01, 2008 at 12:08:56PM +0100, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm using 8.2.6 and I'm observing a trange behaviour using
offset and limits.
Please post
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Stark wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I don't get why a limit is going to change the query plan and most of all
decreasing
the performances.
Until we see the explain analyze it won't be clear what exactly is going
Gaetano Mendola [EMAIL PROTECTED] writes:
I don't get why a limit is going to change the query plan and most of all
decreasing
the performances.
Until we see the explain analyze it won't be clear what exactly is going on.
But in theory a LIMIT can definitely change the plan because the
Greg Stark [EMAIL PROTECTED] writes:
- Index Scan using i_oa_2_00_dt_for on t_oa_2_00_dt dt (cost=0.00..5.31
rows=1 width=8) (actual time=1.264..1.264 rows=0 loops=50)
Index Cond: (dt.card_id = c.id)
Filter: ((_to = 1500) AND (_from = 1550))
Total runtime: 3399960.277 ms
Also, are 1500
On Feb 1, 2008, at 10:42 AM, Luke Porter wrote:
All
Is there an interest in developing bitemporal functionality in
PostgreSQL
Regards
Luke
I can only speak for myself, but- definitely! Based on the googling I
did on bitemporal database, I kind of do this already with
PostgreSQL.
All
Is there an interest in developing bitemporal functionality in PostgreSQL
Regards
Luke From: [EMAIL PROTECTED] Subject: Re: bitemporal functionality for
PostgreSQL To: [EMAIL PROTECTED] Date: Fri, 1 Feb 2008 10:08:03 -0500 Luke
Porter wrote:BruceI have a compelling solution
Luke Porter [EMAIL PROTECTED] writes:
Is there an interest in developing bitemporal functionality in PostgreSQL
Is that anything like the late, mostly unlamented time travel feature?
regards, tom lane
PS: in general, defining what you want with one word and assuming
Gaetano Mendola [EMAIL PROTECTED] writes:
Gregory Stark wrote:
It's evidently guessing wrong about the limit being satisfied early. The
non-indexed restrictions might be pruning out a lot more records than the
planner expects. Or possibly the table is just full of dead records.
Here the
Kevin Grittner [EMAIL PROTECTED] writes:
On Thu, Jan 31, 2008 at 10:19 PM, in message
[EMAIL PROTECTED], Robert Treat
[EMAIL PROTECTED] wrote:
Bad plans from boosting to 100 or less? Or something much higher?
I boosted on a large number of columns based on domains. County
number columns
- Index Scan using i_oa_2_00_dt_for on t_oa_2_00_dt dt
(cost=0.00..5.31 rows=1 width=8) (actual time=1.264..1.264 rows=0 loops=50)
Index Cond: (dt.card_id = c.id)
Filter: ((_to = 1500) AND (_from = 1550))
Total runtime: 3399960.277 ms
Also, are 1500
Gurjeet Singh [EMAIL PROTECTED] writes:
I saw a strange behaviour on one of the production boxes. The
pg_stat_activity shows a process as IDLE and yet 'waiting' !!! On top of
it (understandably, since its IDLE), there are no entries for this pid in
pg_locks!
Hmm, I can reproduce something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
- Index Scan using i_oa_2_00_dt_for on t_oa_2_00_dt dt (cost=0.00..5.31
rows=1 width=8) (actual time=1.264..1.264 rows=0 loops=50)
Index Cond: (dt.card_id = c.id)
Filter: ((_to = 1500) AND
PostgreSQL allows backward reading tuples writing the tuple's length after
and before the tuple proper, in case a 'randomAccess' is requested.
Is there any example of backward reading tuples into PostgreSQL code?
Thanks.
On Fri, 2008-02-01 at 15:42 +, Luke Porter wrote:
All
Is there an interest in developing bitemporal functionality in
PostgreSQL
I am very interested in this topic, and I maintain the pgsql-temporal
project at:
http://pgfoundry.org/projects/temporal/
It's missing good docs and a few
On Thu, Jan 31, 2008 at 10:19 PM, in message
[EMAIL PROTECTED], Robert Treat
[EMAIL PROTECTED] wrote:
On Thursday 31 January 2008 09:55, Kevin Grittner wrote:
I can confirm that I have had performance tank because of boosting
the statistics target for selected columns. It appeared to be
On Fri, 2008-02-01 at 19:25 +0100, [EMAIL PROTECTED] wrote:
PostgreSQL allows backward reading tuples writing the tuple's length
after and before the tuple proper, in case a 'randomAccess' is
requested.
Is there any example of backward reading tuples into PostgreSQL code?
Don't think so,
Andrew Gilligan [EMAIL PROTECTED] writes:
test= CREATE TABLE t2 (LIKE t1 INCLUDING INDEXES);
ERROR: permission denied for tablespace pg_default
How annoying :-(. We could work around this particular manifestation
with a patch to make generateClonedIndexStmt() not set index-tableSpace
if
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-02-01 at 19:25 +0100, [EMAIL PROTECTED] wrote:
PostgreSQL allows backward reading tuples writing the tuple's length
after and before the tuple proper, in case a 'randomAccess' is
requested.
Is there any example of backward reading tuples
The situation seems pretty bad!!
Here are the steps to reproduce in 'PostgreSQL 8.3beta2 on
x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.3.3 (SuSE Linux)':
session 1: begin;
session 1: update test set a = 112 where a = 112;
session 2: update test set a = 113 where a = 112; --waits
Tom Lane [EMAIL PROTECTED] writes:
1. DefineIndex() treats an omitted tablespace clause differently from
explicitly specifying the tablespace that is the database's default:
if you explicitly specify the space then you must have permissions on
it, otherwise you don't need any. (This is the
This page
http://linux-mm.org/OOM_Killer
says that you can hint the OOM killer to be more deferential towards
certain processes.
I am wondering if we can set the system up so that it skips postmaster,
bgwriter etc, and feels more preference towards normal backends (but
then, we would try to
Gurjeet Singh [EMAIL PROTECTED] writes:
The situation seems pretty bad!!
I think at least part of your problem is not understanding that a single
transaction sees a frozen snapshot of pg_stat_activity.
regards, tom lane
---(end of
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
The independent memory size of any child (except a kernel thread) is added
to the score:
/*
* Processes which
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
The independent memory size of any child (except a kernel thread) is added
to the score:
/*
On Feb 1, 2008 3:56 PM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
The situation seems pretty bad!!
I think at least part of your problem is not understanding that a single
transaction sees a frozen snapshot of pg_stat_activity.
It does! I assumed that
On Thu, Jan 31, 2008 at 11:45:55AM +, Simon Riggs wrote:
On Thu, 2008-01-31 at 10:22 +, Gregory Stark wrote:
Decibel! [EMAIL PROTECTED] writes:
CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
Fwiw I would call CLUSTER DDL. Note that it does make a
30 matches
Mail list logo
