it is interesting idea. For me, a significant information from comparation,
so we do some significantly wrong. Memory engine should be faster
naturally, but I don't tkink it can be 1000x.
Yesterday we did a some tests, that shows so for large tables (5G)a our
hashing is not effective. Disabling ha
I dislike it. a too early check means a issues with temporary tables and
mainy new dependency between functions in complex projects. It is some what
we don't want.
Dne 12. 12. 2013 5:30 "Amit Kapila" napsal(a):
> On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane wrote:
> > Amit Kapila writes:
> >> On
Fabien,
>> Included is a proposed fix for this (also fixing weired "remaining"
>> part). If there's no objection, I will commit it.
>
> Looks ok, but I would consider switching to "double" instead of
> "int64".
Assuming you are talking about "remaining sec" part, I agree. Here is
the revised pat
+ hackers
On Thu, Dec 12, 2013 at 12:34 PM, Dev Kumkar wrote:
> On Wed, Dec 11, 2013 at 9:47 PM, Dev Kumkar wrote:
>
>> Actually for searches lower will work.
>> But the other important aspect is 'inserts' which would result 2 rows if
>> the values are 'A' and 'a'. Intent here to have it case in
Hello Tatsuo,
BTW, I saw this with 9.3.2's pgbench:
23930 of 38 tuples (-48%) done (elapsed 226.86 s, remaining -696.10
s).
-48% does not seem to be quite correct to me...
Included is a proposed fix for this (also fixing weired "remaining"
part). If there's no objection, I will
On 06 December 2013 11:57 Amit Kapila wrote:
> On Fri, Nov 29, 2013 at 6:55 PM, Haribabu kommi
> wrote:
> > On 29 November 2013 12:00 Amit Kapila wrote:
> >> On Tue, Nov 26, 2013 at 7:26 PM, Haribabu kommi
> >> wrote:
> >> Few questions about your latest patch:
> >> a. Is there any reason why you
Thank you very much for reporting the problem.
And sorry for this bug and lack of negative tests.
Attempt to access unexisted value cause autoloading of data from the
table to columnar store (because autoload property is enabled by default)
and as far as this entry is not present in the table, t
> BTW, I saw this with 9.3.2's pgbench:
>
> 23930 of 38 tuples (-48%) done (elapsed 226.86 s, remaining
> -696.10 s).
>
> -48% does not seem to be quite correct to me...
Included is a proposed fix for this (also fixing weired "remaining"
part). If there's no objection, I will commit
On Thu, Dec 12, 2013 at 3:43 AM, Peter Eisentraut wrote:
> This patch fails the regression tests; see attachment.
Thanks for reporting the diffs. The reason for failures is that
still decoding for tuple is not done as mentioned in Notes section in
mail
(http://www.postgresql.org/message-id
On Wed, Dec 11, 2013 at 8:31 PM, MauMau wrote:
>>> From: "Amit Kapila"
>
> I re-considered that. As you suggested, I think I'll do as follows. Would
> this be OK?
>
> [pg_ctl.c]
> evtHandle = RegisterEventSource(NULL, *event_source ? event_source :
>"PostgreSQL " PG_MAJORVERSION);
>
>
> [gu
On Wed, Dec 11, 2013 at 6:23 PM, Robert Haas wrote:
> On Tue, Dec 10, 2013 at 9:55 AM, Amit Kapila wrote:
>> Okay, the new way for syntax suggested by Peter has simplified the problem.
>> Please find the updated patch and docs for multiple -g options.
>
> Committed.
Thank you.
With Regards,
Ami
On Wed, Dec 11, 2013 at 10:40 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule
>> wrote:
>>> Now, PG has no any tool for checking dependency between functions and other
>>> objects.
>
>> Isn't that already done for SQL function's (fmgr_sql_validator)?
>> I noticed that "pgbench -s scale_factor" where scale_factor is larger
>> than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing
>> 0 row without any complain. Is there any reason for this?
>
> Oops. It appeared that this was a bug prior 9.3 pgbench. Sorry for noise.
BTW,
On Wed, Dec 4, 2013 at 7:15 PM, Andres Freund wrote:
> There's basically three major 'verbs' that can be performed on a
> stream, currently named (walsender names):
> * INIT_LOGICAL_REPLICATION "name" "output_plugin"
> * START_LOGICAL_REPLICATION "name" last_received ("option_name" value,...)
> *
Peter Eisentraut writes:
> Any other opinions on this out there? All instances of other
> SSL-enabled servers out there, except nginx, default to some variant of
> DEFAULT:!LOW:... or HIGH:MEDIUM: The proposal here is essentially
> to disable MEDIUM ciphers by default, which is explicitly ad
> I noticed that "pgbench -s scale_factor" where scale_factor is larger
> than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing
> 0 row without any complain. Is there any reason for this?
Oops. It appeared that this was a bug prior 9.3 pgbench. Sorry for noise.
Best regard
I noticed that "pgbench -s scale_factor" where scale_factor is larger
than 20,000 (SCALE_32BIT_THRESHOLD) creates pgbench_accounts table containing
0 row without any complain. Is there any reason for this?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.
On Fri, 2013-11-29 at 18:43 +0200, Marko Kreen wrote:
> Well, we should - the DEFAULT is clearly a client-side default
> for compatibility only. No server should ever run with it.
Any other opinions on this out there? All instances of other
SSL-enabled servers out there, except nginx, default to
Hello, we happened to see server crash on archive recovery under
some condition.
After TLI was incremented, there should be the case that the WAL
file for older timeline is archived but not for that of the same
segment id but for newer timeline. Archive recovery should fail
for the case with PANIC
On 2013-12-11 22:08:41 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> > > Andres Freund wrote:
> > > > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > > > > ! if (ISUPDATE_from_mxstatus(members[i].status) &&
> > > >
Andres Freund wrote:
> On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > > > Andres mentioned the idea of sharing some code between
> > > > heap_prepare_freeze_tuple and heap_tuple_needs_freeze, but I haven't
On Wed, Dec 11, 2013 at 3:14 AM, KONDO Mitsumasa
wrote:
>
>> enable_readahead=os|fadvise
>>
>> with os = on, fadvise = off
>
> Hmm. fadvise is method and is not a purpose. So I consider another idea of
> this GUC.
Yeah, I was thinking of opening the door for readahead=aio, but
whatever clearer t
Hi,
Lots of sensible comments removed, I plan to make changes to
address them.
On 2013-12-10 22:17:44 -0500, Robert Haas wrote:
> - I think this needs SGML documentation, same kind of thing we have
> for background workers, except probably significantly more. A design
> document with ASCII art i
2013/12/9 knizhnik
> Hello!
>
> I want to annouce my implementation of In-Memory Columnar Store extension
> for PostgreSQL:
>
> Documentation: http://www.garret.ru/imcs/user_guide.html
> Sources: http://www.garret.ru/imcs-1.01.tar.gz
>
> Any feedbacks, bug reports and suggestions are we
Antonin Houska writes:
> debug_print_plan output contains
> :grpColIdx 2
> in the AGG node.
Hm, that means there's only one grouping column (and it's the second
tlist entry of the child plan node). So that seems conclusive that
the unique-ification is being done wrong. It's not very clear why
t
On 12/11/2013 10:15 PM, Tom Lane wrote:
>
> FWIW, that plan isn't obviously wrong; if it is broken, most likely the
> reason is that the HashAggregate is incorrectly unique-ifying the lower
> table. (Unfortunately, EXPLAIN doesn't show enough about the HashAgg
> to know what it's doing exactly.)
Kevin Grittner writes:
> Tom Lane wrote:
>> FWIW, that plan isn't obviously wrong; if it is broken, most
>> likely the reason is that the HashAggregate is incorrectly
>> unique-ifying the lower table. (Unfortunately, EXPLAIN doesn't
>> show enough about the HashAgg to know what it's doing exactl
On 2013-12-11 14:00:05 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-12-09 19:14:58 -0300, Alvaro Herrera wrote:
> > I don't so much have a problem with exporting CreateMultiXactId(), just
> > with exporting it under its current name. It's already quirky to have
> > both MultiXact
On Tue, Dec 10, 2013 at 1:17 PM, Robert Haas wrote:
> Because the KnownAssignedXIDs and lock tables on the standby need to
> be large enough to contain the largest snapshot and greatest number of
> AccessExclusiveLocks that could exist on the master at any given time.
Right. Initially during the
On 12/11/2013 02:39 PM, Martijn van Oosterhout wrote:
> In this discussion we've mostly used block = 1 postgresql block of 8k.
> But when reading from a disk once you've read one block you can
> basically read the following ones practically for free.
>
> So I wonder if you could make your samplin
>> Hello hackers.
>>
>> I am struggling to understand why standby.max_connections must be higher
>> than
>> primary.max_connections.Do someone know the reason why?
>
> Because the KnownAssignedXIDs and lock tables on the standby need to
> be large enough to contain the largest snapshot and greatest
On Thu, Dec 12, 2013 at 07:22:59AM +1300, Gavin Flower wrote:
> Surely we want to sample a 'constant fraction' (obviously, in
> practice you have to sample an integral number of rows in a page!)
> of rows per page? The simplest way, as Tom suggests, is to use all
> the rows in a page.
>
> However,
I think we're all wet here. I don't see any bias towards larger or smaller
rows. Larger tied will be on a larger number of pages but there will be
fewer of them on any one page. The average effect should be the same.
Smaller values might have a higher variance with block based sampling than
larger
Andres Freund escribió:
> What's your plan to commit this? I'd prefer to wait till Alvaro's
> freezing changes get in, so his patch will look the same in HEAD and
> 9.3. But I think he plans to commit soon.
Yes, I do. I'm waiting on feedback on the patch I posted this
afternoon, so if there's no
On Wed, Dec 11, 2013 at 7:47 PM, Andres Freund
wrote:
>
> I don't think that position has any merit, sorry: Think about the way
> this stuff gets setup. The user creates a new basebackup (pg_basebackup,
> manual pg_start/stop_backup, shutdown primary). Then he creates a
> recovery conf by either s
On Wed, Dec 11, 2013 at 1:28 PM, Simon Riggs wrote:
> But nobody has given a sensible answer to my questions, other than to
> roll out the same general points again. In practice, its a knob that
> does not do very much of use for us. At best it is addressing the
> symptoms, not the cause. IMHO.
I
Daniel Wood wrote:
> In 9.3 I can delete the parent of a parent-child relation if the child row
> is an uncommitted insert and I first update the parent.
Interesting test case, thanks. I traced through it and promptly noticed
that the problem is that HeapTupleSatisfiesUpdate is failing to conside
This patch fails the regression tests; see attachment.
***
/var/lib/jenkins/jobs/postgresql_commitfest_world/workspace/src/test/regress/expected/arrays.out
2013-08-24 01:24:42.0 +
---
/var/lib/jenkins/jobs/postgresql_commitfest_world/workspace/src/test/regress/results/arrays.out
cube.c: In function ‘g_cube_distance’:
cube.c:1453:2: warning: ‘retval’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Oops, did not notice that - thank you!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Let-us-fix-the-documentation-tp5782999p5783002.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On 2013-12-11 14:17:27 -0500, Robert Haas wrote:
> > But in which cases would that actually be slower? There'll be no
> > additional code executed if the hint bits for frozen are set, and in
> > case not it will usually safe us an external function call to
> > TransactionIdPrecedes().
>
> Dunno.
On Wed, December 11, 2013 22:51, AK wrote:
> The following url seems to be slightly incorrect:
>
> http://www.postgresql.org/docs/9.3/static/sql-prepare.html
>
> PREPARE usrrptplan (int) AS
> SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid
> AND l.date = $2;
> EXECUTE usr
The following url seems to be slightly incorrect:
http://www.postgresql.org/docs/9.3/static/sql-prepare.html
PREPARE usrrptplan (int) AS
SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid
AND l.date = $2;
EXECUTE usrrptplan(1, current_date);
I guess the first line of the
Tom Lane wrote:
> FWIW, that plan isn't obviously wrong; if it is broken, most
> likely the reason is that the HashAggregate is incorrectly
> unique-ifying the lower table. (Unfortunately, EXPLAIN doesn't
> show enough about the HashAgg to know what it's doing exactly.)
Yeah, I found myself wis
On 2013-12-11 16:37:54 -0200, Fabrízio de Royes Mello wrote:
> On Wed, Dec 11, 2013 at 6:27 AM, Simon Riggs wrote:
> > >> I think this feature will be used in a lot of scenarios in
> > >> which PITR is currently used.
> > >
> > > We have to judge which is better, we get something potential or to p
On 11 December 2013 19:54, Josh Berkus wrote:
> On 12/11/2013 11:37 AM, Simon Riggs wrote:> On 11 December 2013 17:57,
> Robert Haas wrote:
>>
>>> Extensive testing will be needed to prove
>>> that the new algorithm doesn't perform worse than the current
>>> algorithm in any important cases.
>>
>
On 12/12/13 09:12, Gavin Flower wrote:
On 12/12/13 08:39, Gavin Flower wrote:
On 12/12/13 08:31, Kevin Grittner wrote:
Gavin Flower wrote:
For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes,
using 400 byte pages. In the pathologically worst case, assuming
maximum packing d
Kevin Grittner writes:
> Kevin Grittner wrote:
>> I applied it to master and ran the regression tests, and one of
>> the subselect tests failed.
>>
>> This query:
>>
>> SELECT '' AS six, f1 AS "Correlated Field", f3 AS "Second
>> Field"
>> FROM SUBSELECT_TBL upper
>> WHERE f1 IN
>> (
On 12/11/2013 12:40 PM, Tom Lane wrote:
> Josh Berkus writes:
>> And, for that matter, accepting this patch by no means blocks doing
>> something more sophisticated in the future.
>
> Yeah. I think the only real argument against it is "do we really need
> yet another knob?". Since Josh, who's u
Josh Berkus writes:
> And, for that matter, accepting this patch by no means blocks doing
> something more sophisticated in the future.
Yeah. I think the only real argument against it is "do we really need
yet another knob?". Since Josh, who's usually the voicer of that
argument, is for this on
On Wed, Dec 11, 2013 at 2:49 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> You've got that backwards. We do have the luxury of rejecting new
>>> features until people are generally satisfied that the basic design is
>>> right. There's no overlord decreeing that this must be in 9.4.
>>
>
On 12/12/13 08:39, Gavin Flower wrote:
On 12/12/13 08:31, Kevin Grittner wrote:
Gavin Flower wrote:
For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes,
using 400 byte pages. In the pathologically worst case, assuming
maximum packing density and no page has both types: the l
Kevin Grittner wrote:
> I applied it to master and ran the regression tests, and one of
> the subselect tests failed.
>
> This query:
>
> SELECT '' AS six, f1 AS "Correlated Field", f3 AS "Second
> Field"
> FROM SUBSELECT_TBL upper
> WHERE f1 IN
> (SELECT f2 FROM SUBSELECT_TBL WHERE CAST(
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > The extra catalog tables which store SQL scripts in text columns is one
> > of my main objections to the as-proposed Extension Templates. I view
> > those scripts as a poor man's definition of database object
On 12/11/2013 11:37 AM, Simon Riggs wrote:> On 11 December 2013 17:57,
Robert Haas wrote:
>
>> Extensive testing will be needed to prove
>> that the new algorithm doesn't perform worse than the current
>> algorithm in any important cases.
>
> Agreed, but the amount of testing seems equivalent in b
On Wed, Dec 11, 2013 at 2:37 PM, Simon Riggs wrote:
> On 11 December 2013 17:57, Robert Haas wrote:
>> Extensive testing will be needed to prove
>> that the new algorithm doesn't perform worse than the current
>> algorithm in any important cases.
>
> Agreed, but the amount of testing seems equiva
Robert Haas writes:
>> You've got that backwards. We do have the luxury of rejecting new
>> features until people are generally satisfied that the basic design is
>> right. There's no overlord decreeing that this must be in 9.4.
>
> I strongly agree. PostgreSQL has succeeded because we try not
Robert Haas writes:
> On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane wrote:
>> More generally, if we do go over in 9.4 to the position that PQhost
>> reports the host parameter and nothing but, I'm not sure that introducing
>> a third behavior into the back branches is something that anybody will
>> t
On 12/12/13 08:31, Kevin Grittner wrote:
Gavin Flower wrote:
For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes,
using 400 byte pages. In the pathologically worst case, assuming
maximum packing density and no page has both types: the large rows would
occupy 500 pages and th
On Tue, Dec 10, 2013 at 4:48 PM, Peter Geoghegan wrote:
> Why would I even mention that to a statistician? We want guidance. But
> yes, I bet I could give a statistician an explanation of statistics
> target that they'd understand without too much trouble.
Actually, I think that if we told a stat
On 12/12/13 08:14, Gavin Flower wrote:
On 12/12/13 07:22, Gavin Flower wrote:
On 12/12/13 06:22, Tom Lane wrote:
I wrote:
Hm. You can only take N rows from a block if there actually are at
least
N rows in the block. So the sampling rule I suppose you are using is
"select up to N rows from e
On 11 December 2013 17:57, Robert Haas wrote:
> Extensive testing will be needed to prove
> that the new algorithm doesn't perform worse than the current
> algorithm in any important cases.
Agreed, but the amount of testing seems equivalent in both cases,
assuming we weren't going to skip it for
On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
>>> Robert Haas writes:
Well, returning /tmp on Windows is just stupid. I don't see why we
should feel bad about changing that. A bug is a bug.
>
>>> What I was
On Wed, Dec 11, 2013 at 7:41 AM, Simon Riggs wrote:
> That's about 2-3 days work and I know Peter can hack it. So the
> situation is not perfection-sought-blocking-good, this is more like
> fairly poor solution being driven through when a better solution is
> available within the time and skills a
In 9.3 I can delete the parent of a parent-child relation if the child row
is an uncommitted insert and I first update the parent.
USER1:
drop table child;
drop table parent;
create table parent (i int, c char(3));
create unique index parent_idx on parent (i);
insert into parent values (1, 'AAA');
Gavin Flower wrote:
> For example, assume 1000 rows of 200 bytes and 1000 rows of 20 bytes,
> using 400 byte pages. In the pathologically worst case, assuming
> maximum packing density and no page has both types: the large rows would
> occupy 500 pages and the smaller rows 50 pages. So if one s
Robert Haas writes:
> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, returning /tmp on Windows is just stupid. I don't see why we
>>> should feel bad about changing that. A bug is a bug.
>> What I was suggesting was we should take out the pgunixsocket fallba
On 12/11/2013 09:17 PM, Robert Haas wrote:
On Thu, Nov 21, 2013 at 4:51 PM, Andres Freund wrote:
On 2013-11-21 15:59:35 -0500, Robert Haas wrote:
Separate patch, but yeah, something like that. If we have to mark the
page all-visible, we might as well freeze it while we're there. We
should th
On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
>>> In general, I think the definition of these query functions ought to
>>> be "what was the value of this parameter when the connection was made".
>>> As such, I'm not ev
On 12/12/13 07:22, Gavin Flower wrote:
On 12/12/13 06:22, Tom Lane wrote:
I wrote:
Hm. You can only take N rows from a block if there actually are at
least
N rows in the block. So the sampling rule I suppose you are using is
"select up to N rows from each sampled block" --- and that is going
On Thu, Nov 21, 2013 at 4:51 PM, Andres Freund wrote:
> On 2013-11-21 15:59:35 -0500, Robert Haas wrote:
>> > * Should HeapTupleHeaderXminFrozen also check for FrozenTransactionId?
>> > It seems quite possible that people think they've delt with frozen
>> > xmin entirely after checking, but th
Robert Haas writes:
> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
>> In general, I think the definition of these query functions ought to
>> be "what was the value of this parameter when the connection was made".
>> As such, I'm not even sure that the pgunixsocket behavior that's in
>> PQho
On Wed, Dec 11, 2013 at 10:43 AM, Tom Lane wrote:
>> So while I hear your objection to the "script in catalog" idea Stephen,
>> I think we should move forward. We don't have the luxury of only
>> applying patches where no compromise has to be made, where everyone is
>> fully happy with the solutio
"k...@rice.edu" wrote:
> The question I have, which applies to the matview support as
> well, is "How can we transparently substitute usage of the
> in-memory columnar store/matview in a SQL query?".
My take on that regarding matviews is:
(1) It makes no sense to start work on this without a f
Atri Sharma writes:
> On Wed, Dec 11, 2013 at 11:12 PM, Peter Eisentraut wrote:
>> Is there a reason why you can't get this directly from the OS?
> I would say that its more of a convenience to track the usage directly
> from the database instead of setting up OS infrastructure to store it.
The
On 12/11/13, 5:06 AM, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
>> I think you are mistaken. My patch includes all changes between your v1
>> and v2 patch.
>
> I mistakenly remembered that we did remove all the is_event_trigger
> business from the plperl patch too, when it's not the cas
Josh Berkus writes:
> However, it would really be useful to have an extra tag (in addition to
> the ERROR or FATAL) for "If you're seeing this message, something has
> gone seriously wrong on the server." Just stuff like corruption
> messages, backend crashes, etc.
Right, we've discussed that id
On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund
>> wrote:
>>> One use case is accessing a particular host when using DNS round robin
>>> to standbys in combination with SSL.
>
>> Ah, interesting point. And it's not incon
On Wed, Dec 11, 2013 at 11:25 AM, Andres Freund wrote:
> On 2013-12-10 19:11:03 -0500, Robert Haas wrote:
>> Committed #1 (again). Regarding this:
>>
>> + /* XXX: we could also do this unconditionally, the space is used
>> anyway
>> + if (copy_oid)
>> + HeapTupleSetOid(
On Wed, Dec 11, 2013 at 6:27 AM, Simon Riggs wrote:
>
> On 11 December 2013 06:36, KONDO Mitsumasa
> wrote:
>
> >> I think this feature will be used in a lot of scenarios in
> >> which PITR is currently used.
> >
> > We have to judge which is better, we get something potential or to
protect
> > s
On 12/11/2013 09:57 AM, Robert Haas wrote:
> I don't agree with that assessment. Anything that involves changing
> the scheduling of autovacuum is a major project that will legitimately
> provoke much controversy. Extensive testing will be needed to prove
> that the new algorithm doesn't perform
On Wed, Dec 11, 2013 at 10:08 AM, knizhnik wrote:
> 1. Calls in PL/pgSQL are very slow - about 1-2 micsroseconds at my computer.
> Just defining insertion per-row trigger with empty procedure increase time
> of insertion of 6 million records twice - from 7 till 15 seconds. If trigger
> procedure i
On 12/12/13 06:22, Tom Lane wrote:
I wrote:
Hm. You can only take N rows from a block if there actually are at least
N rows in the block. So the sampling rule I suppose you are using is
"select up to N rows from each sampled block" --- and that is going to
favor the contents of blocks containi
On 12/12/13 06:22, Tom Lane wrote:
I wrote:
Hm. You can only take N rows from a block if there actually are at least
N rows in the block. So the sampling rule I suppose you are using is
"select up to N rows from each sampled block" --- and that is going to
favor the contents of blocks containi
On Wed, Dec 11, 2013 at 11:12 PM, Peter Eisentraut wrote:
> On 12/10/13, 5:08 PM, Tom Lane wrote:
>> Having said that, I can't get very excited about this feature anyway,
>> so I'm fine with rejecting the patch. I'm not sure that enough people
>> care to justify any added overhead at all. The lo
On Wed, Dec 11, 2013 at 10:41 AM, Simon Riggs wrote:
> It looks fairly easy to estimate the memory needed for an auto vacuum,
> since we know the scale factor and the tuple estimate. We can then use
> the memory estimate to alter the scheduling of work. And/or we can use
> actual memory usage and
Hi.
I've improved the patch.
It works in expanded mode when either format option is set to wrapped
(\pset format wrapped), or we have no pager, or pager doesn't chop long
lines (so you can still use the trick).
Target output width is taken from either columns option (\pset columns 70),
or environm
On 12/10/13, 5:08 PM, Tom Lane wrote:
> Having said that, I can't get very excited about this feature anyway,
> so I'm fine with rejecting the patch. I'm not sure that enough people
> care to justify any added overhead at all. The long and the short of
> it is that network traffic generally is wh
On 12/11/2013 08:48 AM, Tom Lane wrote:
> The fundamental problem IMO is that you want to complicate the definition
> of what these things mean as a substitute for DBAs learning something
> about Postgres. That seems like a fool's errand from here. They're going
> to have to learn what FATAL mean
From: "Kevin Grittner"
5. FATAL: terminating walreceiver process due to administrator
command
6. FATAL: terminating background worker \"%s\" due to
administrator command
Those are client connections and their backends terminated for a
reason other than the client side of the connection request
I wrote:
> Hm. You can only take N rows from a block if there actually are at least
> N rows in the block. So the sampling rule I suppose you are using is
> "select up to N rows from each sampled block" --- and that is going to
> favor the contents of blocks containing narrower-than-average rows.
Andres Freund writes:
> On 2013-12-11 10:07:19 -0500, Tom Lane wrote:
>> Do you remember offhand where the failures are?
> No, but they are easy enough to reproduce. Out of 10 runs, I've attached
> the one with the most failures and checked that it seems to contain all
> the failures from other r
From: "Andres Freund"
On 2013-12-12 00:31:25 +0900, MauMau wrote:
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \"%s\" due to administrator
command
Those are important if they happen outside a shutdown. So, if you really
want
"MauMau" writes:
> I agree that #1-#3 are of course reasonable when there's any client the user
> runs. The problem is that #1 (The database system is starting up) is output
> in the server log by pg_ctl. In that case, there's no client the user is
> responsible for. Why does a new DBA have
Kevin Grittner writes:
> Kevin Grittner wrote:
>> Tom Lane wrote:
>>> I haven't touched matview.sql here; that seems like a distinct issue.
>> I'll fix that.
> Done.
Thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 2013-12-10 19:11:03 -0500, Robert Haas wrote:
> Committed #1 (again). Regarding this:
>
> + /* XXX: we could also do this unconditionally, the space is used
> anyway
> + if (copy_oid)
> + HeapTupleSetOid(key_tuple, HeapTupleGetOid(tp));
>
> I would like to put in a
Hi,
I depends on what you mean by "transparently substitute".
I f you want to be able to execute standard SQL queries using columnar
store, then it seems to be impossible without rewriting of executor.
I provided another approach based on calling standard functions which
perform manipulations n
Robert Haas writes:
> On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund wrote:
>> One use case is accessing a particular host when using DNS round robin
>> to standbys in combination with SSL.
> Ah, interesting point. And it's not inconceivable that some
> application out there could be using PQho
Hello!
Implementation of IMCS itself took me about two months (with testing and
writing documentation).
But huge part of the code was previously written by me for other
projects, so I have reused them.
Most of the time I have spent in integration of this code with
PostgreSQL (I was not so fami
From: "Tom Lane"
Jim Nasby writes:
On 12/9/13 5:56 PM, Tom Lane wrote:
How so? "FATAL" means "an error that terminates your session", which
is exactly what these are.
Except in these cases the user never actually got a working session;
their request was denied.
To be clear, from the cli
1 - 100 of 152 matches
Mail list logo
