>
>
> > > 2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
> > >
> > I do not get the point of "VERBOSE".
> > As far as I understand, explain analyze (without verbose) will anyway add
> > overhead for calculation of "gets/hits/cpu". Why discard that information
> in
> > "non
"Vladimir Sitnikov" <[EMAIL PROTECTED]> wrote:
> > 2. EXPLAIN ANALYZE VERBOSE shows buffer statistics in 'actual' section.
> >
> I do not get the point of "VERBOSE".
> As far as I understand, explain analyze (without verbose) will anyway add
> overhead for calculation of "gets/hits/cpu". Why disc
"Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
> I was assigned to review this.
Thanks for your reviewing.
I assume that the basic concepts are ok and focus of discussion is in:
- New counters in struct Instrumentation.
(buffer usage and CPU usage)
- Should EXPLAIN ANALYZE show those counter
Hi,
On Mon, Dec 8, 2008 at 11:39 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>>
>>> To set or clear the flag from PGPROC, to send or handle a signal, we have
>>> to acquire ProcArrayLock. Is that safe to do in a signal h
Hi,
I saw a report at .br mailing list [1] complaining about the message's title.
I do not try to investigate it. Am I missing something?
euler=# select attname from pg_attribute where attnum > 0 and attnum <>
ALL(select conkey from pg_constraint where conrelid = attrelid and contype =
'p');
ER
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they read but might not be stable, are
not supposed to be shared. If they are it's a mistake.
Looks like the ArchiveHandle variable 'AH' and the TocEntry
'next_work_item' are not being deep copie
Andrew Dunstan wrote:
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they wr
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they re
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
if(h)
CloseHandle(h);
Umm, even if I wait on the handle usi
Andrew Chernow wrote:
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been
unable to get parallel restore to work with Windows threading. No
doubt I am missing something, but I really don't know what. Unless
someone can tell me what I am doing wrong, I hav
Hi,
On Mon, Dec 8, 2008 at 10:36 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
>>> BTW, on what platforms signal doesn't interrupt sleep?
>
>> In theory, none.
>
> In practice, the
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
* run parallel steps
Hi,
On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki <[EMAIL PROTECTED]> wrote:
> I understood your point. In the case of synchronous replication,
> because slave fails over when master crashes, there're no need to
> leave FPW from the beginning.
>
> In this case, only prefetch will work. Fujii's
Simon Riggs wrote:
> On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
> I assume that could just be always enabled.
It is not "always" enabled. When we build it with SE-PostgreSQL feature,
"Mark Wong" <[EMAIL PROTECTED]> writes:
> On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Are any of the queries complicated enough to trigger GEQO planning?
> Is there a debug option that we could use to see?
Well, you could set geqo=off and see if the behavior changes, bu
On Tue, Dec 2, 2008 at 2:25 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
>> ... where the "Power Test" seems to oscillate between degrees of good and bad
>> behavior seemingly at random.
>
> Are any of the queries complicated enough to trigger GEQO planning?
Is
Hello,
I've been bit by this about a million times:
select (func()).* executes the function once per each field in the
returned tuple. See the example below:
create function foo_func() returns foo as
$$
declare f foo;
begin
raise notice '!';
return f;
end;
$$ language plpgsql;
po
Tom Lane wrote:
> [ still catching up on back email ]
>
> [EMAIL PROTECTED] (Magnus Hagander) writes:
>> Properly unregister OpenSSL callbacks when libpq is done with
>> it's connection. This is required for applications that unload
>> the libpq library (such as PHP) in which case we'd otherwise
>
[ still catching up on back email ]
[EMAIL PROTECTED] (Magnus Hagander) writes:
> Properly unregister OpenSSL callbacks when libpq is done with
> it's connection. This is required for applications that unload
> the libpq library (such as PHP) in which case we'd otherwise
> have pointers to these f
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> It's strange, when I repeat tests, I get usually times about 10 ms,
> but cca cca every 5 test it is about 2ms
Hmm. The theory I'd developed for what I see here is that the "slow"
timings correspond to when the pgstat code decides it needs a new stats
On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
> Tom Lane wrote:
> > KaiGai Kohei <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian wrote:
> >>> I assume that could just be always enabled.
> >
> >> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> >> rest of enhanced
Josh Williams wrote:
> Hi folks,
>
> Was recently poked and reminded that this patch may be of interest to
> the community. It was mostly done as an academic exercise, just to see
> how it works, and so it has a rather hackish feel. The patch adds the
> sequence owner, if available, to psql's
It's strange, when I repeat tests, I get usually times about 10 ms,
but cca cca every 5 test it is about 2ms
postgres=# VACUUM x;
VACUUM
Time: 12,093 ms
postgres=# VACUUM x;
VACUUM
Time: 1,928 ms
postgres=# VACUUM x;
VACUUM
Time: 10,743 ms
postgres=# VACUUM x;
VACUUM
Time: 1,927 ms
postgres=# VACU
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Bruce Momjian wrote:
>>> I assume that could just be always enabled.
>
>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
>> rest of enhanced security features (includes the row-level ACL) are
>> disabled automa
[EMAIL PROTECTED] writes:
> the infinite loop occurs in fsm_search_avail when called for the 32nd
> time.
... which is the first time that the initial test doesn't make it fall
out immediately.
Would you add a couple more printouts, along the line of
nodeno = target;
while (nod
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
>> Obviously, this happens because the locale support functions in
>> backend/regex/regc_locale.c are (presumably intentionally)
>> crippled so as not to support non-ascii chars, despite all the
>>
On Dec 5, 2008, at 7:50 PM, Andrew Gierth wrote:
While waiting for a large restore to complete (and investigating why
parts of it were so slow), I came across this scenario. This isn't
quite the same as some previous discussion of hint bits, but I thought
it was something that could probably be t
On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote:
Agreed, default values should not be a part of function signatures,
although it might be nice if ALTER FUNCTION to allow default values
to be changed.
It would be VERY nice. I routinely cut and paste an entire function
header to later
On Mon, Dec 8, 2008 at 11:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> That might only be the case when the pg_statistic record is in shared
>> buffers.
>
> Yeah, it seems unlikely that disabling compression is a good idea in the
> bigger scheme of things.
Greg Stark <[EMAIL PROTECTED]> writes:
> That might only be the case when the pg_statistic record is in shared
> buffers.
Yeah, it seems unlikely that disabling compression is a good idea in the
bigger scheme of things.
> Also I wonder if eqjoinsel and company might need to be made more
> toa
Gregory Stark <[EMAIL PROTECTED]> writes:
> But I can also see Tom's reluctance. It's a fair increase in the amount of
> code to maintain in that file for a pretty narrow use case. On the other hand
> it looks like it would be all in that file. The planner wouldn't have to do
> anything special to
[ a bit off-topic for the thread, but ... ]
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'll attach the query and plan. You'll note that the query looks a
> little odd, especially all the (1=1) tests.
FWIW, it would be better to use "TRUE" as a placeholder in your
generated queries. I don't
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I assume that could just be always enabled.
> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> rest of enhanced security features (includes the row-level ACL) are
> disabled automatically, as we discussed
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/12/8 Heikki Linnakangas <[EMAIL PROTECTED]>:
>> How did you measure that?
> it's simple test
> create table x(a integer, b integer);
> insert into x select i, i from generate_series(1,1000) g(i);
> and then vacuum on 8.3.5 and vacuum on current
2008/12/8 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>
>> I did small tests and I found so for small tables (less 1000 rows)
>> VACUUM based on visibility maps are slower than old implementation
>>
>> it is about 5ms X 20ms
>
> How did you measure that?
it's simple test
creat
I wrote:
> ... In particular we should at least try to bypass the pg_proc scan when
> there are *no* function stats records.
That idea, at least, looks to be trivial to implement; so I'll go do so.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Andrew Dunstan wrote:
Andrew Chernow wrote:
I think what is missing is a way to deny the execution of queries that
don't operate on an object (like a table, sequence, role, schema,
etc...), OR queries not covered by the priv system. Object-based
queries can be locked down using the existi
Dear all,
On Mon, 8 Dec 2008, Heikki Linnakangas wrote:
Date: Mon, 08 Dec 2008 09:17:52 +0200
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Zdenek Kotala <[EMAIL PROTECTED]>,
pgsql-hackers list
Subject: Re: [HACKERS] cvs head initdb han
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In the end, it would be better if this function was not called at all
> for user-invoked vacuum, and have autovacuum handle it. However, that
> doesn't work for people who disable autovacuum.
A possible variant on that is to invoke it only in database-
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Oprofile suggests that most of the time is actually spent in
> pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
> called by pgstat_vacuum_stat.
> We added support for tracking call counts and elapsed runtime of
> user-define
Heikki Linnakangas escribió:
> Oprofile suggests that most of the time is actually spent in
> pgstat_vacuum_stat. And more precisely in pstat_collect_oids, which is
> called by pgstat_vacuum_stat.
Hmm, that routine is expensive. Calling it for every vacuum is not good
:-( Fortunately, autov
> Well, new features that have a perfectly acceptable and usable
> workaround typically have a fairly low priority of fixing :-)
Putting something in the TODO list doesn't make it a priority. But it
indicates that it's something that the community would like to see
fixed, if anyone is interested
To be honest, for me back patching would mean only that I don't have
to recompile, and resend binaries to clients, after 8.1->8.3 upgrade
(to utilize enums, and domains).
I don't think it would break any apps tho.
so in my case, obviously +1 +1 :)
--
Sent via pgsql-hackers mailing list (pgs
On Mon, 2008-12-08 at 12:01 +0200, Heikki Linnakangas wrote:
> I haven't testsed, but it looks to me that the recovery.conf reading
> patch doesn't work in EXEC_BACKEND mode (= Windows). You'll need to add
> recoveryRestoreCommand to save/read_backend_parameters in postmaster.c.
That comment h
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of an
Pavel Stehule wrote:
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
How did you measure that?
I tried to reproduce that here, and indeed it seems to be much slower on
CVS HEAD than o
On Mon, 2008-12-08 at 10:04 +0200, Heikki Linnakangas wrote:
> And is the performance impact of that acceptable?
No, but I think we already agreed to change that to a separate lwlock.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-h
On Mon, Dec 8, 2008 at 8:01 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>> Well, new features that have a perfectly acceptable and usable
>> workaround typically have a fairly low priority of fixing :-)
>>
>> Since tables are basically types, I'm not sure what the differen
On Sat, 2008-12-06 at 17:55 +0900, Fujii Masao wrote:
> Yeah, it's my imagination about the real situation after 8.4 release,
> especially I considered about the future conjugal life of Synch Rep and
> Hot Standby ;) Waiting to redo until the file fills might lead to marital
> breakdown.
You're
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
>> BTW, on what platforms signal doesn't interrupt sleep?
> In theory, none.
In practice, they exist. In particular I can demonstrate the issue
on HPUX 10.20. I also dispute
Andrew Gierth <[EMAIL PROTECTED]> writes:
> Obviously, this happens because the locale support functions in
> backend/regex/regc_locale.c are (presumably intentionally) crippled so
> as not to support non-ascii chars, despite all the code there using
> wide chars for everything otherwise.
It's not
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> To set or clear the flag from PGPROC, to send or handle a signal, we
> have to acquire ProcArrayLock. Is that safe to do in a signal handler?
No. If it's trying to do that then it's broken. In fact, if it's
trying to do much of anything beyond s
Greg Stark <[EMAIL PROTECTED]> writes:
> How would it break any apps?
Well, this would change the set of possible matches for ambiguous
function calls. So it's not out of the question that you could get
ambiguous-function failures that didn't happen before.
regards, tom l
Merlin Moncure wrote:
On Sun, Dec 7, 2008 at 10:17 PM, Robert Haas <[EMAIL PROTECTED]> wrote:
On Sun, Dec 7, 2008 at 7:57 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Dmitry Koterov wrote:
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL ve
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee <[EMAIL PROTECTED]>wrote:
>
>
> On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas <
> [EMAIL PROTECTED]> wrote:
>
>>
>> If you see a straightforward way, please submit a patch!
>>
>>
> Will do that.
>
>
Here is a patch which implements this. The PD
On Sun, Dec 7, 2008 at 10:17 PM, Robert Haas <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 7:57 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> Dmitry Koterov wrote:
>>> Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
>>> PostgreSQL version?
>>
>> It is not currentl
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I did small tests and I found so for small tables (less 1000 rows)
> VACUUM based on visibility maps are slower than old implementation
>
> it is about 5ms X 20ms
Hm, Presumably this is on a machine where the visibility map is entirely in
c
Hello,
I did small tests and I found so for small tables (less 1000 rows)
VACUUM based on visibility maps are slower than old implementation
it is about 5ms X 20ms
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Dec 08, 2008 at 01:12:39PM +0200, Heikki Linnakangas wrote:
> If a signal is received just before pq_wait call, after checking
> replication_requested, pq_wait won't be interrupted and will wait up to
> a second before responding to it.
>
> BTW, on what platforms signal doesn't interrupt
In walsender, in the main loop that waits for backend requests to send
WAL, there's this comment:
+ /*
+* Nap for the configured time or until a request arrives.
+*
+* On some platforms, signals won't interrupt the sleep. To
ensure
I haven't testsed, but it looks to me that the recovery.conf reading
patch doesn't work in EXEC_BACKEND mode (= Windows). You'll need to add
recoveryRestoreCommand to save/read_backend_parameters in postmaster.c.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
How would it break any apps? They would hve to be depending on passing
arrays as anynonarray? That seems unlikely.
On the other hand I don't see much reason to backpatch. It's not like
anyone is going to run into this problem unexpectedly on a running
system. It just doesn't seem like a ba
Greg Stark wrote:
Does this signal multiplexing solve the "out of signals" problem we have
generally?
It's a general solution, but it relies on flags in PGPROC, so it'll only
work for backends and auxiliary processes that have a PGPROC entry.
--
Heikki Linnakangas
EnterpriseDB http://w
Does this signal multiplexing solve the "out of signals" problem we
have generally? I need another signal for the progress indicator too.
Or is this only useful for other users which need the same locks or
other resources?
--
Greg
On 8 Dec 2008, at 08:04, Heikki Linnakangas <[EMAIL PROTEC
This came up on irc:
postgres=# show lc_ctype;
lc_ctype
-
fr_FR.UTF-8
postgres=# show server_encoding;
server_encoding
-
UTF8
(1 row)
postgres=# select E'\303\201' ILIKE E'\303\241';
?column?
--
t
(1 row)
postgres=# select E'\303\201' ~* E'\303\
I've been looking at the signal handling part of the synchronous
replication patch. It looks OK, but one thing makes me worry.
To set or clear the flag from PGPROC, to send or handle a signal, we
have to acquire ProcArrayLock. Is that safe to do in a signal handler?
And is the performance impa
On Dec 8, 2008, at 2:46 AM, Tom Lane wrote:
Comments?
+1
If this is agreed to be a bug, should we consider
back-patching it? (I'd vote not, I think, because the behavioral
change could conceivably break some apps that work now.)
+1
Best,
David
--
Sent via pgsql-hackers mailing list (p
68 matches
Mail list logo
