Zdenek Kotala napsal(a):
Joshua D. Drake napsal(a):
Tom Lane wrote:
I think the wiki TODO needs to be broken into multiple pages. How can
we go about that?
I would think the easiest thing to do would be to break up the page
into categories. Either via difficulty or type of fix (administ
Joshua D. Drake napsal(a):
Tom Lane wrote:
I think the wiki TODO needs to be broken into multiple pages. How can
we go about that?
I would think the easiest thing to do would be to break up the page into
categories. Either via difficulty or type of fix (administrative,
planner, etc...)
Tom Lane wrote:
So, if you edit the current version of the TODO page, you get this stern
warning:
WARNING: This page is 106 kilobytes long; some browsers may have
problems editing pages approaching or longer than 32kb. Please consider
breaking the page into smaller sections.
Hmm ... my browse
So, if you edit the current version of the TODO page, you get this stern
warning:
> WARNING: This page is 106 kilobytes long; some browsers may have
> problems editing pages approaching or longer than 32kb. Please consider
> breaking the page into smaller sections.
Hmm ... my browser isn't failin
Steve Atkins <[EMAIL PROTECTED]> writes:
> On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote:
>> Personally I think it's rather nice to be able to have some extra
>> flexibility in how psql prints out data. Maybe, instead of the dry
>> and uninformative 'border 2', there could be a set of ouput co
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote:
>> After playing with it for a little bit, I'm not convinced that it buys
>> enough performance win to be worth applying --- the restriction of cache
>> lifespan to one tuple cycle of a TupleTableSlot is awf
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> You would have to test for whether it's time to sleep much more often.
>> Possibly before every ExecProcNode call would be enough.
>
> That would have overhead comparable to EXPLAIN ANALYZE, which is a lot.
I do
Gregory Stark <[EMAIL PROTECTED]> writes:
> You would have to test for whether it's time to sleep much more often.
> Possibly before every ExecProcNode call would be enough.
That would have overhead comparable to EXPLAIN ANALYZE, which is a lot.
I'm fairly dubious about this whole proposal: it's
Hi,
In the manual for SET ROLE, it's noted that an invocation of SET ROLE
will leave the session_user unchanged, but will change the current_user.
Invoking pg_stat_activity after the SET ROLE is changed will however
leave the usename unchanged. (Also from the manual we note that a
snapshot is ta
Btw, I forgot to mention in my original post that one interesting use
case that is not application specific, is to apply cost limits on
pg_dump. That would be one of the final goals for me.
> I think the experience with vacuum was that cost_delay was a mistake. The only
> parameter users really ou
On Mon, 25 Aug 2008 22:39:54 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> But I think we should consider removing the {auto,}vacuum_cost_delay
> parameter or at least hiding and undocumenting it. It's a foot-gun
> and serves no useful purpose that merely lowering the
> {auto,}vacuum_cost_limi
"Peter Schuller" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I'd like to have a stab at implementing cost delays, for regular
> INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for
> VACUUM and the autovacuum limits; one may have application specific
> bulk operations that need exec
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> bruce wrote:
>>> Tom Lane wrote:
Currently, config.sgml still describes the new "enum" GUC variables
as being of type "string" --- but pg_settings says they are "enum".
This is not very consistent, but I wonder whether ch
Hello,
I'd like to have a stab at implementing cost delays, for regular
INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for
VACUUM and the autovacuum limits; one may have application specific
bulk operations that need executing without adverseley affecting
latency/throughput of
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
>> To me the issue is what we consider IN and BETWEEN and similar
>> constructs to "mean", which in a datatype world boils down to choosing
>> which of the datatype's operators to implemen
On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > ISTM the problem is that there's no easy way to refer to "operators
> > found in a default opclass", so perhaps we could invent a construct:
>
> > A OPERATOR(btree,2) B
>
> Huh? I d
> Yes, but always in relation to operator classes, so from BTrees opclass or
> such, which I refered to as "the context of index searches", as I don't
> really see any theorical need for opclass if it's not for indexing.
IIRC analyze uses the btree op class to build the selectivity histogram.
-Na
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> ... I don't really see any theorical need for opclass if
> it's not for indexing.
Well, if we were starting from a green field, we might design it
differently, but I see little point in changing the system structure
now that it's established. You n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 25 août 08 à 16:48, Tom Lane a écrit :
But, IIRC, only in the context of index searches, not at the
planner level.
No, that's not true at all. There are lots and lots of places now
where
we use btree and/or hash operator classes to reas
On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote:
On Sun, Aug 24, 2008 at 2:00 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]>
wrote:
On Sat, 23 Aug 2008 14:57:50 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
Also, having now looked at the proposed patch, it seems clear that
it
isn't addressing the i
On Mon, 25 Aug 2008 13:56:16 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > That is what I was suggesting.
> >
>
> Why should the xlog directory be treated specially?
Consider the following:
mount /dev/sda1 /var/lib/pgsql
mount /dev/sdb1 /srv1/pgsql/pg_xlog (which has a link
from /
Joshua Drake wrote:
Is there some reason why initdb shouldn't just Do The Right Thing™
when it finds an empty extant $PGDATA/pg_xlog directory that passes
the same tests an empty extant $PGDATA would?
That is what I was suggesting.
Why should the xlog directory be treated speci
On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote:
> After playing with it for a little bit, I'm not convinced that it buys
> enough performance win to be worth applying --- the restriction of cache
> lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.
> (For example, sorts that
On Mon, 25 Aug 2008 10:12:03 -0700
David Fetter <[EMAIL PROTECTED]> wrote:
> > /var/lib/pgsql/data/ exists but is empty you can initdb within that
> > directory. However if there is anything in it you can not. You are
> > asking that if pg_xlog exists but is empty that we still be able to
> > use
On Mon, Aug 25, 2008 at 09:54:26AM -0700, Joshua D. Drake wrote:
> On Mon, 25 Aug 2008 09:42:21 -0700
> David Fetter <[EMAIL PROTECTED]> wrote:
>
> > > We either need to provide a way to initialize it at initdb, allow
> > > xlogs to be in table space or add a GUC for the location.
> >
> > There's
David Fetter wrote:
On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
While initdb allows you to choose a directory for transaction
logs, it can't already exist, so it can't be in its usual place
under $PGDATA. I'd like to propose that
On 25-Aug-08, at 10:43 AM, Alvaro Herrera wrote:
Dave Cramer wrote:
Well, I go the extra mile and kill any remaing autovac procs
Here are the logs
2008-08-25 04:00:01 EDT [32276] LOG: autovacuum launcher shutting
down
2008-08-25 04:00:01 EDT [20526] LOG: autovacuum launcher started
David Fetter wrote:
There's already a way to specify where xlogs should be via
-X/--xlogdir. What that doesn't do is put the xlogdir where a DBA
would naturally expect to find it. When that DBA doesn't find it in
the place they expect, very bad knock-on decisions are likely to
result.
I don't
On Mon, 25 Aug 2008 09:42:21 -0700
David Fetter <[EMAIL PROTECTED]> wrote:
> > We either need to provide a way to initialize it at initdb, allow
> > xlogs to be in table space or add a GUC for the location.
>
> There's already a way to specify where xlogs should be via
> -X/--xlogdir.
Sorry sho
On Mon, Aug 25, 2008 at 09:29:03AM -0700, Joshua D. Drake wrote:
> On Mon, 25 Aug 2008 09:04:01 -0700
> David Fetter <[EMAIL PROTECTED]> wrote:
>
> > > > When -X is set to "existing", it would check whether pg_xlog
> > > > is a directory and the only thing in $PGDATA. One way to do
> > > > that i
On Mon, 25 Aug 2008 09:04:01 -0700
David Fetter <[EMAIL PROTECTED]> wrote:
> > > When -X is set to "existing", it would check whether pg_xlog is a
> > > directory and the only thing in $PGDATA. One way to do that is to
> > > add a new return code to check_data_dir() and a new branch of the
> > >
On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > While initdb allows you to choose a directory for transaction
> > logs, it can't already exist, so it can't be in its usual place
> > under $PGDATA. I'd like to propose that this be allowed by
On Mon, 25 Aug 2008 08:40:17 -0700
David Fetter <[EMAIL PROTECTED]> wrote:
> Folks,
>
> While initdb allows you to choose a directory for transaction logs, it
> can't already exist, so it can't be in its usual place under $PGDATA.
> I'd like to propose that this be allowed by having an alternate
David Fetter <[EMAIL PROTECTED]> writes:
> While initdb allows you to choose a directory for transaction logs, it
> can't already exist, so it can't be in its usual place under $PGDATA.
> I'd like to propose that this be allowed by having an alternate syntax
> for the -X option, namely, "existing."
Folks,
While initdb allows you to choose a directory for transaction logs, it
can't already exist, so it can't be in its usual place under $PGDATA.
I'd like to propose that this be allowed by having an alternate syntax
for the -X option, namely, "existing."
When -X is set to "existing", it would
I wrote:
> [ squint... ] Actually, it looks like the stats collector SIG_IGNores
> SIGHUP? That can't be right (any more) can it?
Oh, never mind, I see my hour-old CVS pull is obsolete ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I think this is introducing complication and race conditions to solve a
>>> problem that no one will really care about. Just let people change the
>>> filename at SIGHUP and document that doing that on-the-fly may
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this is introducing complication and race conditions to solve a
>> problem that no one will really care about. Just let people change the
>> filename at SIGHUP and document that doing that on-the-fly may cause
>> stats querie
So I was starting to implement an exprLocation() function according to
previous discussion
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01131.php
and I wondered where to put it. One idea is next to exprType() in
parser/parse_expr.c, but that seems a bit unsatisfactory because it's
likel
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Actually, I think maybe not so hard. Attached is a patch that fixes
>> this. It's done by keeping the old filename around. When you change the
>> path, the stats collector will start writing the new file the next time
>> it writes som
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le lundi 25 août 2008, Gregory Stark a écrit :
>> I'm not sure it's made explicit anywhere in the documentation but those
>> properties *are* what btree operator classes define. You would end up
>> duplicating the same structures (like, LT is meaningle
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote:
>> My own feeling is that we should avoid imputing particular semantics
>> to particular operator names, and so these constructs should always be
>> defined by reference to operators found
Dave Cramer wrote:
> Well, I go the extra mile and kill any remaing autovac procs
>
> Here are the logs
>
> 2008-08-25 04:00:01 EDT [32276] LOG: autovacuum launcher shutting down
> 2008-08-25 04:00:01 EDT [20526] LOG: autovacuum launcher started
What did you SIGHUP, the launcher or postmaster
On Monday 25 August 2008 04:24:23 Tom Lane wrote:
> Seems to me that what this boils down to is whether we want to read the
> spec literally ("it says the construct is defined in terms of operators
> named >= and <=, therefore we should do that") or by intent (obviously
> what they *want* is a cons
Dave Cramer wrote:
> Since a number of people actually do this it would seem like a better
> way to temporarily suspend autovac should be on the todo ?
No -- what you are doing is documented to work. However, it only stops
the autovac launcher, not a currently-running worker. If this isn't
wo
On 24-Aug-08, at 10:17 PM, Alvaro Herrera wrote:
Hi Dave,
Dave Cramer wrote:
I'd like to stop autovac by changing the conf file then sending the
server a HUP
This "appears" to work, the logs show autovac terminated by
administrative command. Then a few minutes later I see a vacuum
process
On 24-Aug-08, at 10:12 PM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
I'd like to stop autovac by changing the conf file then sending the
server a HUP
Uh ... why should that stop an autovac already in progress? I'd
only expect it to affect future launches.
Well, I go the ext
Le lundi 25 août 2008, Gregory Stark a écrit :
> I'm not sure it's made explicit anywhere in the documentation but those
> properties *are* what btree operator classes define. You would end up
> duplicating the same structures (like, LT is meaningless unless you
> associate it with the correspondin
"Dimitri Fontaine" <[EMAIL PROTECTED]> writes:
> Le lundi 25 août 2008, Martijn van Oosterhout a écrit :
>> ISTM the problem is that there's no easy way to refer to "operators
>> found in a default opclass", so perhaps we could invent a construct:
>
> Perhaps here again we're showing a need for so
Le lundi 25 août 2008, Martijn van Oosterhout a écrit :
> ISTM the problem is that there's no easy way to refer to "operators
> found in a default opclass", so perhaps we could invent a construct:
Perhaps here again we're showing a need for some higher level semantics about
operators and types. T
Tom Lane wrote:
[ off-list ]
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I'm not sure how important it will really be once we have support for
dead-space-map-driven vacuum.
Is that something we can expect any time soon? I haven't heard much
about it really happening fo
Hello
2008/8/24 Martijn van Oosterhout <[EMAIL PROTECTED]>:
> On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote:
>> So I feel that the proposal for labeled parameters as such is dead
>> in the water, and that the only usefulness this thread has had is
>> (re-) exploring the syntactic altern
52 matches
Mail list logo
