On Thu, 4 Dec 2008, Gregory Stark wrote:
Incidentally I got this wrong in my previous email. If we're aiming at
8.4->8.5 as the first in-place update then we actually don't need this in 8.4
at all.
I don't know about everybody else, but I haven't give up on putting
together something that wor
/*
* Size of the bitmap on each visibility map page, in bytes. There's no
* extra headers, so the whole page minus except for the standard page
header
* is used for the bitmap.
*/
#define MAPSIZE (BLCKSZ - SizeOfPageHeaderData)
ISTM that we should MAXALIGN the SizeOfPageHeaderData to compute
/*
* We don't need to lock the page, as we're only looking at a single
bit.
*/
result = (map[mapByte] & (1 << mapBit)) ? true : false;
Isn't this a dangerous assumption to make ? I am not so sure that even a bit
can be read atomically on all platforms. I think the only caller of
Hello,
On Fri, Dec 5, 2008 at 12:09 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> I was expecting you to have walreceiver and startup share an end of WAL
>> address via shared memory, so that startup never tries to read past end.
>> That way we would be able to begin reading a WAL file *before* it
ISTM that the PD_ALL_VISIBLE flag and the visibility map bit can be set at
the end of pruning operation if we know that there are only tuples visible
to all transactions left in the page. The way pruning is done, I think it
would be straight forward to get this information.
Thanks,
Pavan
--
Pava
On Fri, 5 Dec 2008, Robert Haas wrote:
OK, I did this. I actually tried 10 .. 100 in increments of 10 and
then 100 ... 1000 in increments of 50, for 7 different queries of
varying complexity
Great bit of research. Was this against CVS HEAD or an 8.3 database?
--
* Greg Smith [EMAIL PROTECTE
On Thu, Nov 27, 2008 at 6:46 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> ANALYZE with default_statistics_target set to 10 takes 13 s. With
>> 100, 92 s. With 1000, 289 s.
>
> That is interesting. It would also be interesting to total up the time it
> takes to run EXPLAIN (without ANALYZE) for
Alvaro Herrera escreveu:
> I've already modified your patch a bit ... please send your updated
> patch so I can merge it into mine. However, my changes were also
> relatively minor. Since Tom wants it to be entirely rewritten then
> maybe merging minor fixes to it is a waste of time ...
>
Since
On Wed, 3 Dec 2008, Bruce Momjian wrote:
As the author of the original shell script, which was in
/contrib/pg_upgrade, I think the code has grown to the point where it
should be reimplemented in something like Perl.
Ah, there's the common ancestor I couldn't find. Sheesh, you learn Perl
las
Bruce Momjian wrote:
KaiGai Kohei wrote:
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't remove features via
configure unless it is f
KaiGai Kohei wrote:
> >> I don't oppose to elimination of "--disable-row-acl" options, however,
> >> it is not clear for me whether it should be unavoidable selection in
> >> the future, or not.
> >
> > Look at the existing configure options; we don't remove features via
> > configure unless it i
I don't oppose to elimination of "--disable-row-acl" options, however,
it is not clear for me whether it should be unavoidable selection in
the future, or not.
Look at the existing configure options; we don't remove features via
configure unless it is for some platform-specific reason. Please
On Thu, 2008-12-04 at 21:51 -0500, Greg Smith wrote:
> On Thu, 4 Dec 2008, Robert Haas wrote:
>
> > Just let's please change it both places, rather than letting
> > contrib/pgtune be a backdoor to get around not liking what initdb does.
> > And similarly with the other parameters...
>
> Someone
Hi,
On Thu, Dec 4, 2008 at 6:29 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> The only sensible settings are
> synchronous_commit = on, synchronous_replication = on
> synchronous_commit = on, synchronous_replication = off
> synchronous_commit = off, synchronous_replication = off
>
> This doesn't ma
On Thu, 4 Dec 2008, Robert Haas wrote:
Just let's please change it both places, rather than letting
contrib/pgtune be a backdoor to get around not liking what initdb does.
And similarly with the other parameters...
Someone running pgtune has specifically asked for their database to be
tuned
KaiGai Kohei wrote:
> >> If you have anything to comment for the patches, could you disclose it?
> >> It is not necessary to be a comprehensive one. Don't hesitate to submit.
> >
> > I looked over the patch and was wondering why you chose to have a
> > configure option to disable row-level ACLs.
>
Hi,
On Thu, Dec 4, 2008 at 6:11 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-12-03 at 14:22 +0900, Koichi Suzuki wrote:
>
>> > There's clearly a huge gain using prefetch, when we have
>> > full_page_writes = off. But that does make me think: Why do we need
>> > prefetch at all if we
On Thu, Dec 4, 2008 at 5:11 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Thu, 4 Dec 2008, Kevin Grittner wrote:
>
>> I think there needs to be some easy way to choose an option which
>> yields a configuration similar to what we've had in recent production
>> releases -- something that will start
Greg Smith wrote:
On Thu, 4 Dec 2008, Ron Mayer wrote:
OTOH there tends to be less DBA time available to tune the smaller
demo instances that come&go as sales people upgrade their laptops; so
improved automation would be much appreciated there.
I have a TODO list for things that might be int
>
> "Vladimir Sitnikov" <[EMAIL PROTECTED]> writes:
>
> > I wish there was a way to get the results of explain into some table. I
> wish
> > it was the default output "format". That would make life of pgAdmin
> easier,
> > and improve readability even in psql. Do not you think there is something
>
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Gregory Stark wrote:
>
>> They all seem functional ideas. But it seems to me they're all ideas that
>> would be appropriate if this was a pgfoundry add-on for existing releases.
>
> I was mainly trying to target things that would be achi
Mark Cave-Ayland wrote:
On Thu, 2008-12-04 at 13:51 -0800, Kevin Neufeld wrote:
Wow, that's bad. I just updated to PostgreSQL 8.3.5 from 8.3.3 and I now get
the same thing.
test=# create temp table tmp as select st_makepoint(random(), random()) as
the_geom from generate_series(1, 1);
SE
> Not being familiar with the code, my assumption was that it would be
> possible to push all the tuples involved off to another page as if they'd
> been updated, with WAL logging and everything, similarly to the ideas that
> keep getting kicked around for creating extra space for header expansion.
>>> Greg Smith <[EMAIL PROTECTED]> wrote:
> On Thu, 4 Dec 2008, Kevin Grittner wrote:
>
>> I think there needs to be some easy way to choose an option which
>> yields a configuration similar to what we've had in recent
production
>> releases -- something that will start up and allow minimal testi
"Vladimir Sitnikov" <[EMAIL PROTECTED]> writes:
> I wish there was a way to get the results of explain into some table. I wish
> it was the default output "format". That would make life of pgAdmin easier,
> and improve readability even in psql. Do not you think there is something
> wrong with havi
On Thu, 4 Dec 2008, Kevin Grittner wrote:
I think there needs to be some easy way to choose an option which
yields a configuration similar to what we've had in recent production
releases -- something that will start up and allow minimal testing on
even a small machine.
But that's the goal of w
On Thu, 4 Dec 2008, Gregory Stark wrote:
They all seem functional ideas. But it seems to me they're all ideas that
would be appropriate if this was a pgfoundry add-on for existing releases.
I was mainly trying to target things that would be achievable within the
context of the existing shell
>>> Greg Smith <[EMAIL PROTECTED]> wrote:
> On Thu, 4 Dec 2008, Ron Mayer wrote:
>
>> OTOH there tends to be less DBA time available to tune the smaller
demo
>> instances that come&go as sales people upgrade their laptops; so
>> improved automation would be much appreciated there.
>
> I have a
> 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 verbose" mode? Just to make th
On Thu, 4 Dec 2008, Ron Mayer wrote:
OTOH there tends to be less DBA time available to tune the smaller demo
instances that come&go as sales people upgrade their laptops; so
improved automation would be much appreciated there.
I have a TODO list for things that might be interesting to add to
On Thu, 2008-12-04 at 14:05 -0600, Kevin Grittner wrote:
> >>> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> > Fair enough, then make sure you are demoing on a platform that can
> > handle PostgreSQL :)
>
> There are a lot of good reasons for people to be running an instance
> of PostgreSQL
Zdenek Kotala napsal(a):
Hi all,
I attached pg_upgrade.sh script patch which works now for 8.3->8.4. It
is contrib module in contrib/pg_upgrade directory. Just make/make
install and it works.
I forget to mention that default datetime format is different now. Please, use
same datetime format
tmp <[EMAIL PROTECTED]> writes:
> Regarding whether it's worth the effort: In each of my three past jobs (all
> using postgresql) I have met several queries that would fetch a small subset
> of
> a large - even huge - input. I think that types of queries are relatively
> common out there, but if
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Fair enough, then make sure you are demoing on a platform that can
> handle PostgreSQL :)
There are a lot of good reasons for people to be running an instance
of PostgreSQL on a small machine, running it on a machine with other
software, or ru
On Thu, Dec 04, 2008 at 05:57:01PM +0100, Zdenek Kotala wrote:
> Hi all,
>
> I attached pg_upgrade.sh script patch which works now for 8.3->8.4. It is
> contrib module in contrib/pg_upgrade directory. Just make/make install
> and it works.
Kudos!
> 4) script is written in ksh. It has several pr
In principle, if there are no aggregate functions, then nodeAgg could
return a row immediately upon making any new entry into the hash table.
Whether it's worth the code uglification is debatable ... I think it
would require a third major pathway through nodeAgg.
Regarding whether it's worth the
On Thu, 2008-12-04 at 10:55 -0800, Ron Mayer wrote:
> Joshua D. Drake wrote:
> > Although I get your point, that is a job for sqllite not postgresql.
> > PostgreSQL is not a end all be all solution and it is definitely not
> > designed to be "embedded" which is essentially what you are suggesting
Joshua D. Drake wrote:
On Thu, 2008-12-04 at 10:20 -0800, Ron Mayer wrote:
Greg Smith wrote:
I'm not the sort to be too concerned myself that
the guy who thinks he's running a DW on a system with 64MB of RAM might
get bad settings, but it's a fair criticism to point that out as a problem.
In
On Thu, 2008-12-04 at 18:38 +0100, Magnus Hagander wrote:
> Do the RPM initscript by any chance pass something like '-A "ident
> sameuser"' to initdb? If so, that's where the fix needs to go. Initdb
> defaults to "trust"...
Good catch. So, AFAICS running initdb with
-A ident
will do the trick.
>> In defense of thinking about very small configurations, I've seen many
>> cases where an enterprise-software salesperson's laptop is running a
>> demo - either in a small virtual machine in the laptop, or on an
>> overloaded windows box.Even though the customer might end up
>> running with 6
Well that's a bit if hyperbole. There's a gulf of difference between
an embedded use case where it should fit within an acceptable
footprint for a desktop app component of maybe a megabyte or so of ram
and disk - if we're generous and saying it should run comfortably
without having to spec
On Thu, 2008-12-04 at 10:20 -0800, Ron Mayer wrote:
> Greg Smith wrote:
> > I'm not the sort to be too concerned myself that
> > the guy who thinks he's running a DW on a system with 64MB of RAM might
> > get bad settings, but it's a fair criticism to point that out as a problem.
>
> In defense
Greg Smith wrote:
I'm not the sort to be too concerned myself that
the guy who thinks he's running a DW on a system with 64MB of RAM might
get bad settings, but it's a fair criticism to point that out as a problem.
In defense of thinking about very small configurations, I've seen many
cases wh
2008/12/4 Peter Eisentraut <[EMAIL PROTECTED]>:
> It's committed.
>
great,
thank you
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>>> Gregory Stark <[EMAIL PROTECTED]> wrote:
> And log the explain plans to a
> file so we can look for at what statistics targets the plan changed?
Well, I can give you explain analyze output for
default_statistics_target 10 and 50, for whatever that's worth.
Unfortunately I blew my save from
It's committed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Devrim GÜNDÜZ wrote:
On Thu, 2008-12-04 at 19:20 +0200, Peter Eisentraut wrote:
The hba file format has changed. Your simplest fix would be to remove
the "sameuser".
This is a file created by initdb -- so is it a bug?
If it were a bug in our sources the buildfarm would be broke
Devrim GÜNDÜZ wrote:
> On Thu, 2008-12-04 at 19:20 +0200, Peter Eisentraut wrote:
>> The hba file format has changed. Your simplest fix would be to remove
>> the "sameuser".
>
> This is a file created by initdb -- so is it a bug?
Do the RPM initscript by any chance pass something like '-A "ident
On Thu, 2008-12-04 at 19:20 +0200, Peter Eisentraut wrote:
> The hba file format has changed. Your simplest fix would be to remove
> the "sameuser".
This is a file created by initdb -- so is it a bug?
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
On Thursday 04 December 2008 17:19:28 Devrim GÜNDÜZ wrote:
> This is a fresh snapshot -- is also happened on Nov 28th snapshot, too:
>
> -bash-3.2$ pg_ctl start
> server starting
> -bash-3.2$ LOG: authentication option not in name=value format: sameuser
>
> CONTEXT: line 70 of configuration file
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> There are some very big tables in that query which contain some
> confidential data.
oh well.
> I'll attach the query and plan. You'll note that the query looks a
> little odd, especially all the (1=1) tests.
That is interesting. I seem to rec
Hi all,
I attached pg_upgrade.sh script patch which works now for 8.3->8.4. It is
contrib module in contrib/pg_upgrade directory. Just make/make install and it works.
There are two changes from previous 8.1->8.2.
1) pg_largeobject is also upgraded
2) added check for dropped column
And now ho
>>> Gregory Stark <[EMAIL PROTECTED]> wrote:
> That sounds like it would be an interesting query to analyze in more
detail.
> Is there any chance to could run the complete graph and get a chart
of
> analyze
> times for all statistics values from 1..1000 ? And log the explain
plans to
> a
> fil
This is a fresh snapshot -- is also happened on Nov 28th snapshot, too:
-bash-3.2$ pg_ctl start
server starting
-bash-3.2$ LOG: authentication option not in name=value format: sameuser
CONTEXT: line 70 of configuration file "/var/lib/pgsql/data/pg_hba.conf"
FATAL: could not load pg_hba.conf
L
Hello.
I can successfully ALTER a NON-EMPTY table (ct) which ROWTYPE is used as a
column type for another table (dt):
CREATE TABLE ct (id INTEGER);
CREATE TABLE dt (id INTEGER, c ct);
INSERT INTO dt VALUES(1, '(666)');
SELECT * FROM dt;
-- (1, '(666)')
ALTER TABLE ct ADD COLUMN n INTEGER;
SELEC
Pavan Deolasee escribió:
> On Thu, Dec 4, 2008 at 2:25 AM, Alvaro Herrera
> <[EMAIL PROTECTED]>wrote:
>
> > Yeah, that was plenty silly. Updated patch attached.
>
> Looks good me to, except for this warning:
Applied. Many thanks for the exhaustive testing.
--
Alvaro Herrera
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> You mean like this?
>>
>> postgres=# explain select distinct x from i limit 5;
>> QUERY PLAN
>> ---
>> Limit (cost=54.50..54.51 ro
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> Does that know to stop scanning as soon as it has seen 5 distinct values?
Uhm, hm. Apparently not :(
postgres=# create or replace function v(integer) returns integer as $$begin
raise notice 'called %', $1; return $1; end$
Gregory Stark wrote:
tmp <[EMAIL PROTECTED]> writes:
If the input is "sufficiently" large and the LIMIT threshold "sufficiently"
small, maintain the DISTINCT output by hashning while traversing the input and
stop when the LIMIT threshold is reached. No sorting required and *at* *most*
one rea
tmp <[EMAIL PROTECTED]> writes:
> If the input is "sufficiently" large and the LIMIT threshold "sufficiently"
> small, maintain the DISTINCT output by hashning while traversing the input and
> stop when the LIMIT threshold is reached. No sorting required and *at* *most*
> one read of input.
You
Bruce Momjian wrote:
> Kris Jurka wrote:
>> Magnus Hagander wrote:
>>> Log Message:
>>> ---
>>> 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
>
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Gregory Stark napsal(a):
>
>> How about adding a special syntax for CREATE TABLE which indicates to include
>> a dropped column in that position? Then pg_dump could have a -X option to
>> include those columns as placeholders. Something like:
>>
>> CREAT
As far as I have understood the following query
SELECT DISTINCT foo
FROM bar
LIMIT baz
is done by first sorting the input and then traversing the sorted data,
ensuring uniqueness of output and stopping when the LIMIT threshold is
reached. Furthermore, a part of the sort procedure is to tra
The following query causes an assertion failure on CVS head:
SELECT * FROM (SELECT 1 AS i) AS a WHERE NOT EXISTS (SELECT 1 WHERE 1 <> i);
TRAP: FailedAssertion("!(!bms_is_empty(min_righthand))", File: "initsplan.c",
Line: 685)
Looks like it's assuming there's at least one relation on each side
On Thu, 4 Dec 2008, Heikki Linnakangas wrote:
Date: Thu, 04 Dec 2008 13:19:15 +0200
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zdenek Kotala <[EMAIL PROTECTED]>,
pgsql-hackers list
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
[EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 2:25 AM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
>
>
> Yeah, that was plenty silly. Updated patch attached.
>
>
Looks good me to, except for this warning:
snapmgr.c: In function 'RegisterSnapshot':
snapmgr.c:356: warning: unused variable 'snap'
Thanks,
Pavan
--
Pavan D
Gregory Stark napsal(a):
How about adding a special syntax for CREATE TABLE which indicates to include
a dropped column in that position? Then pg_dump could have a -X option to
include those columns as placeholders. Something like:
CREATE TABLE foo (
col1 integer,
NULL COLUMN,
col2 integer
)
On Thu, 2008-12-04 at 12:41 +0100, Magnus Hagander wrote:
> > Understood. Is the periodic renegotiation of keys something that would
> > interfere with the performance or robustness of replication? Is the
> > delay likely to effect sync rep? I'm just checking we've thought about
> > it.
>
> It w
Simon Riggs wrote:
> On Thu, 2008-12-04 at 17:57 +0900, Fujii Masao wrote:
>
>> On Wed, Dec 3, 2008 at 3:38 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> Do we need to worry about periodic
>> renegotiation of keys in be-secure.c?
> What is "keys" you mean?
See the notes in that fi
Greg Smith <[EMAIL PROTECTED]> writes:
> Here's a good example; that seems a perfect problem for somebody else to work
> on. I understand it now well enough to float ideas without even needing to
> see
> your code. Stop worring about it, I'll grab responsibility for making sure it
> gets done b
[EMAIL PROTECTED] wrote:
On Wed, 3 Dec 2008, Heikki Linnakangas wrote:
Could you zip up the FSM file of that relation (a file called e.g
"789_fsm"), and send it over? Or the whole data directory, it
shouldn't be that big.
you get both.
Thanks. Hmm, the FSM pages are full of zeros, as I wo
On Wed, 3 Dec 2008, Heikki Linnakangas wrote:
Date: Wed, 03 Dec 2008 20:29:01 +0200
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zdenek Kotala <[EMAIL PROTECTED]>,
pgsql-hackers list
Subject: Re: [HACKERS] cvs head initdb hangs on unixware
[EMAIL PROTECTED] wrote:
On Thu, 4 Dec 2008, Zdenek Kotala wrote:
The TOAST problem is already addressed and script should handle it correctly.
But I don't like it much, because it is kind of magic.
I just read through the whole "toast by chunk-end" thread again and it
does seem pretty complicated. What is the magic
On Thu, 2008-12-04 at 16:10 +0900, Fujii Masao wrote:
> > * Diagram on p.2 has two Archives. We have just one (yes)
>
> No, we need archive in both the primary and standby. The primary needs
> archive because a base backup is required when starting the standby.
> Meanwhile, the standby needs arc
On Thu, 2008-12-04 at 17:57 +0900, Fujii Masao wrote:
> On Wed, Dec 3, 2008 at 3:38 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
> >>> > Do we need to worry about periodic
> >>> > renegotiation of keys in be-secure.c?
> >>>
> >>> What is "keys" you mean?
> >>
> >> See the notes in that file for exp
On Wed, 2008-12-03 at 14:22 +0900, Koichi Suzuki wrote:
> > There's clearly a huge gain using prefetch, when we have
> > full_page_writes = off. But that does make me think: Why do we need
> > prefetch at all if we use full page writes? There's nothing to prefetch
> > if we can keep it in cache.
Greg Smith napsal(a):
On Wed, 3 Dec 2008, Zdenek Kotala wrote:
It works fine for 8.3->8.4 too, but I'm working on cleanup and fixing
bugs. I hope that I will send updated version to community today.
That would be great. It didn't feel like you were quite done with it
yet. I'll be glad to he
Hi,
On Wed, Dec 3, 2008 at 3:38 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>>> > Do we need to worry about periodic
>>> > renegotiation of keys in be-secure.c?
>>>
>>> What is "keys" you mean?
>>
>> See the notes in that file for explanation.
>
> Thanks! I would check it.
The key is used only whe
Greg Smith <[EMAIL PROTECTED]> writes:
> On Thu, 4 Dec 2008, Gregory Stark wrote:
>
>> My point was more that you could have a data warehouse on a non-dedicated
>> machine, you could have a web server on a non-dedicated machine, or you could
>> have a mixed server on a non-dedicated machine.
>
> I
79 matches
Mail list logo
