On 05/08/14 17:56, Mark Kirkwood wrote:
Adding in the 'if' in the float8 case increases run time to 4s. So looks
like plpgsql might have a slightly higher cost for handling added
conditionals. Be interesting to dig a bit more and see what is taking
the time.
Thinking about this a bit more, I
Hi Claudio,
I think there has been a misunderstanding. I agree with you (and I
think also Marco) that LSN is definitely a component to consider in
this process. We will come up with an alternate proposal which
considers LSNS either today or tomorrow. ;)
Thanks,
Gabriele
--
Gabriele Bartolini -
On Mon, Aug 4, 2014 at 11:48 PM, testman1316 wrote:
> In both we ran code that did 1 million square roots (from 1 to 1 mill). Then
> did the same but within an If..Then statement.
> Note: once we started running queries on the exact same data in Oracle and
> PostgreSQL we saw a similar pattern. O
I've been working away at allowing semi and anti joins to be added to the
list of join types that our join removal code supports.
The basic idea is that we can removal a semi or anti join if the left hand
relation references the relation that's being semi/anti joined if the join
condition matches
Hi Kyotaro,
I looked at the patches and felt that the approach taken here is too
intrusive, considering that the feature is only for foreign scans.
There are quite a few members added to the generic Path, Plan structures,
whose use is is induced only through foreign scans. Each path now stores
two
On Wed, Jul 16, 2014 at 4:34 AM, Pavel Stehule wrote:
>
>
>
> 2014-07-15 12:07 GMT+02:00 Fujii Masao :
>
>> On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule
>> wrote:
>> >
>> >
>> >
>> > 2014-07-15 11:29 GMT+02:00 Fujii Masao :
>> >
>> >> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule
>> >>
>> >>
On Tue, Jul 29, 2014 at 7:07 PM, wrote:
> I have improved the patch by making following changes:
>
> 1. Since stream_stop() was redundant, stream_stop() at the time of WAL file
> closing was deleted.
>
> 2. Change the Flash judging timing for the readability of source code.
>I have changed
On Tue, Aug 5, 2014 at 9:04 PM, Fujii Masao wrote:
> On Tue, Jul 29, 2014 at 7:07 PM, wrote:
>> I have improved the patch by making following changes:
>>
>> 1. Since stream_stop() was redundant, stream_stop() at the time of WAL file
>> closing was deleted.
>>
>> 2. Change the Flash judging tim
Em segunda-feira, 4 de agosto de 2014, testman1316
escreveu:
>
> SET SERVEROUTPUT ON
> SET TIMING ON
>
> DECLARE
> n NUMBER := 0;
> BEGIN
> FOR f IN 1..1000
> LOOP
> n := SQRT (f);
> END LOOP;
>
>
In addition to the other suggestions that have been posted (using a
procedural languag
On Sat, Aug 2, 2014 at 1:40 AM, Heikki Linnakangas
wrote:
> I ran this through my WAL page comparison tool to verify that all the WAL
> record types are replayed correctly (although I did some small cleanup
after
> that, so it's not impossible that I broke it again; will re-test before
> committin
On Wed, Jul 23, 2014 at 5:21 PM, Pavan Deolasee
wrote:
> 1. Need for compressing full page backups:
> There are good number of benchmarks done by various people on this list
> which clearly shows the need of the feature. Many people have already voiced
> their agreement on having this in core, eve
Roberto Mello wrote:
> In addition to the other suggestions that have been posted (using
> a procedural language more suitable to mathematical ops, etc) I
> noticed that you are using a RAISE in the PostgreSQL version that
> you are not in Oracle.
>
> I am curious as to what the difference is if
On Tue, Aug 5, 2014 at 9:50 AM, Kevin Grittner wrote:
>
> Since that is outside the loop, the difference should be nominal;
Apologies. I misread on my phone and though it was within the loop.
> and in a quick test it was. On the other hand, reducing the
> procedural code made a big difference.
hi, all
I already can debug general postgres using "ddd" and "select
pg_backend_pid();" , now, I want to study the details of the system
catalog cache and system cache management, so I need to debug the function
InitPostgres() and InitCatalogCache(), and I tried the following steps:
[refer: How
On Tue, Jul 15, 2014 at 10:45 PM, Magnus Hagander wrote:
> On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane wrote:
>> I wrote:
>>> In short, maybe we ought to invent a new category PGC_SU_BACKEND (not
>>> wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to
>>> PGC_USERSET, ie same when-
On 08/05/2014 12:56 AM, Mark Kirkwood wrote:
The moral of the story for this case is that mapping Oracle to Postgres
datatypes can require some careful thought. Using 'native' types (like
integer, float8 etc) will generally give vastly quicker performance.
We've seen a lot of this ourselves. O
You are correct sir, 4.1 seconds. Are you a consulant? We ae looking for a
Postgresql guru for advice. We are doing a proof of concept of Postgresql on
AWS
From: Mark Kirkwood-2 [via PostgreSQL]
[mailto:ml-node+s1045698n5813763...@n5.nabble.com]
Sent: Tuesday, August 05, 2014 12:58 AM
To: R
On Thu, Jun 5, 2014 at 4:43 AM, Amit Kapila wrote:
> I have improved the patch by making following changes:
> a. Improved the bgwriter logic to log for xl_running_xacts info and
> removed the hibernate logic as bgwriter will now work only when
> there is scarcity of buffer's in free list
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote:
>> > If you want to do that, it's fine with me. What I would do is:
>> >
>> > - Back-patch the addition of the sparcv8+ stuff all the way. If
>> > anyone's running anything older, let them complain...
>> > - Remove the special case for MIPS wi
On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo
wrote:
> I'd definitely replace /arg/argument/. Furthermore I'd avoid the form
> "argument 1: something is wrong": the string is likely to end up in
> sentences with other colons so I'd rather use "something is wrong at
> argument 1".
>
> Is the pat
Using the 'include' keyword in postgresql.conf let's us do groovy things
like paste together pieces of general purpose configs into the working file.
-- But since all we can do is set/reset the parameters the possibility
of concatenating fragments that use some of the list parameters won't
On 4 August 2014 19:30, Claudio Freire wrote:
> On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
> wrote:
>>I really like the proposal of working on a block level incremental
>> backup feature and the idea of considering LSN. However, I'd suggest
>> to see block level as a second step and a
On Sat, Aug 2, 2014 at 6:58 PM, Peter Geoghegan wrote:
> On Sat, Aug 2, 2014 at 2:45 AM, Peter Geoghegan wrote:
>> I'll post something over the weekend.
>
> Attached is a cumulative pair of patches generated using
> git-format-patch. I refer anyone who wants to know how the two parts
> fit togeth
On Tue, Aug 5, 2014 at 12:03 PM, Robert Haas wrote:
> ...but I'm wondering what underlies that decision. I would
> understand the decision to go that way if it simplified things
> elsewhere, but in fact it seems that's what underlies the addition of
> ssup_operator to SortSupportData, which in t
On Tue, Aug 5, 2014 at 12:03 PM, Robert Haas wrote:
> and if some opclass other than text wants to
> provide a sortsupport shim that supplies a comparator only sometimes,
> it will need its own copy of the logic.
That's true, but my proposal to do things that way reflects the fact
that text is a
On Sun, Aug 3, 2014 at 3:29 PM, Gavin Flower
wrote:
> So it would probably be a good idea to mention in the relevant
> documentation, that there was no Year Zero, and that 1 AD follows directly
> after 1 BC.
Well, maybe. By and large, the PostgreSQL documentation should
confine itself to documen
On Tue, Aug 5, 2014 at 3:15 PM, Peter Geoghegan wrote:
> On Tue, Aug 5, 2014 at 12:03 PM, Robert Haas wrote:
>> and if some opclass other than text wants to
>> provide a sortsupport shim that supplies a comparator only sometimes,
>> it will need its own copy of the logic.
>
> That's true, but my
On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO wrote:
>> This patch is pretty trivial.
> Another slightly less trivial but more useful version.
>
> The issue is that there are 3 definitions of modulo, two of which are fine
> (Knuth floored division and Euclidian), and the last one much less useful.
On Mon, Aug 4, 2014 at 10:38 AM, Heikki Linnakangas
wrote:
> Now that we use TAP for testing client tools, I think we can use that to
> test various SSL options too. I came up with the attached. Comments?
>
> It currently assumes that the client's and the server's hostnames are
> "postgres-client.
On Mon, Aug 4, 2014 at 11:35 AM, Manuel Kniep wrote:
> I’m missing the PG_RETURN_UINT16 macro in fmgr.h
> Since we already have the PG_GETARG_UINT16 macro
> I guess it makes sense to to have it.
>
> here is the trivial patch for it.
I see no reason not to add this. Anyone else want to object?
-
On 08/05/2014 11:12 AM, Jerry Sievers wrote:
> shared_preload_libraries += auto_explain
>
> Would do the trick.
>
> I've never heard this mentioned before so presume not many have
> contemplated this.
It's been discussed.
However, other than shared_preload_libraries, I can't think of a GUC
whi
On Tue, Aug 5, 2014 at 12:33 PM, Robert Haas wrote:
> Per your other email, here's the patch again; hopefully I've got the
> right stuff in the file this time.
Your patch looks fine to me. I recommend committing patch 1 with these
additions. I can't think of any reason to rehash the 2012 discussi
On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
> On 08/05/2014 11:12 AM, Jerry Sievers wrote:
> > shared_preload_libraries += auto_explain
> >
> > Would do the trick.
> >
> > I've never heard this mentioned before so presume not many have
> > contemplated this.
>
> It's been discu
On Tue, Aug 5, 2014 at 3:23 PM, Simon Riggs wrote:
> On 4 August 2014 19:30, Claudio Freire wrote:
>> On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
>> wrote:
>>>I really like the proposal of working on a block level incremental
>>> backup feature and the idea of considering LSN. However
Robert Haas wrote:
> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO wrote:
> >> This patch is pretty trivial.
> > Another slightly less trivial but more useful version.
> >
> > The issue is that there are 3 definitions of modulo, two of which are fine
> > (Knuth floored division and Euclidian), and
Bruce Momjian wrote:
> On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
> > On 08/05/2014 11:12 AM, Jerry Sievers wrote:
> > > shared_preload_libraries += auto_explain
> > >
> > > Would do the trick.
> > >
> > > I've never heard this mentioned before so presume not many have
> > > co
On Tue, Aug 5, 2014 at 9:35 AM, Robert Haas wrote:
> On Sat, Aug 2, 2014 at 9:15 AM, Daniele Varrazzo
> wrote:
> > I'd definitely replace /arg/argument/. Furthermore I'd avoid the form
> > "argument 1: something is wrong": the string is likely to end up in
> > sentences with other colons so I'd
On Tue, Aug 5, 2014 at 12:33 PM, Robert Haas wrote:
> I'm also not sure it won't come up again. There are certainly other
> text-like datatypes out there that might want to optimize sorts; e.g.
> citext.
Fair enough. Actually, come to think of it I find BpChar/character(n)
a far more likely cand
On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
> On Thu, Jul 10, 2014 at 06:17:14PM -0400, Bruce Momjian wrote:
> > Well, we are going to need to call internal C functions, often bypassing
> > their typical call sites and the assumption about locking, etc. Perhaps
> > this could be
Alvaro Herrera-9 wrote
> Bruce Momjian wrote:
>> On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
>> > On 08/05/2014 11:12 AM, Jerry Sievers wrote:
>> > > shared_preload_libraries += auto_explain
>> > >
>> > > Would do the trick.
>> > >
>> > > I've never heard this mentioned before s
On 08/05/2014 04:41 PM, Alvaro Herrera wrote:
> I have chosen to keep the name "minmax", even if the opclasses now let
> one implement completely different things on top of it such as geometry
> bounding boxes and bloom filters (aka bitmap indexes). I don't see a
> need for a rename: essentially,
On 5 August 2014 22:38, Claudio Freire wrote:
>> * When we take an incremental backup we need the WAL from the backup
>> start LSN through to the backup stop LSN. We do not need the WAL
>> between the last backup stop LSN and the new incremental start LSN.
>> That is a huge amount of WAL in many
There was some informal discussion of worst case performance of my
text sort support patch at the most recent developer's meeting in
Ottawa. There is no need to repeat the details here, which aren't
terribly interesting - I made a point about putting worst case
performance in context. I also made a
On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
>
> On 5 August 2014 22:38, Claudio Freire wrote:
> Thinking some more, there seems like this whole store-multiple-LSNs
> thing is too much. We can still do block-level incrementals just by
> using a single LSN as the reference point. We'd still
2014-08-05 22:08 GMT+08:00 土卜皿 :
> hi, all
> I already can debug general postgres using "ddd" and "select
> pg_backend_pid();" , now, I want to study the details of the system
> catalog cache and system cache management, so I need to debug the function
> InitPostgres() and InitCatalogCache(), a
Bruce Momjian writes:
> On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
>> However, other than shared_preload_libraries, I can't think of a GUC
>> which would benefit from this. Can you?
> search_path?
Given the security implications of search_path, assembling its value
from indepe
David G Johnston wrote:
> Alvaro Herrera-9 wrote
> > I think this merits a new GUC flag, say GUC_LIST_ADDITIVE.
>
> Would that allow, without any special syntax, multiple declarations of, say,
> shared_preload_libraries, to have their values appended instead of the most
> (or least, I forget whic
On Tue, Aug 5, 2014 at 9:17 PM, Michael Paquier
wrote:
> On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
>>
>> On 5 August 2014 22:38, Claudio Freire wrote:
>> Thinking some more, there seems like this whole store-multiple-LSNs
>> thing is too much. We can still do block-level incrementals ju
On Tue, Aug 5, 2014 at 9:04 PM, Simon Riggs wrote:
> On 5 August 2014 22:38, Claudio Freire wrote:
>
>>> * When we take an incremental backup we need the WAL from the backup
>>> start LSN through to the backup stop LSN. We do not need the WAL
>>> between the last backup stop LSN and the new incre
On 08/05/2014 06:25 PM, Alvaro Herrera wrote:
> I'm not sold on += as the syntax to use. It just needs to be something
> different from =.
Alternative is to use "+" in the value string:
shared_preload_libraries = '+auto_explain'
... not sure that's better.
The alternative is to add an "appen
Josh Berkus writes:
> BTW, while there's unlikely to be a good reason to put search_path in
> pg.conf with appends, there are a LOT of reasons to want to be able to
> append to it during a session.
[shrug...] You can do that today with current_setting()/set_config().
reg
On Wed, Aug 6, 2014 at 09:17:35AM +0900, Michael Paquier wrote:
> On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
> >
> > On 5 August 2014 22:38, Claudio Freire wrote:
> > Thinking some more, there seems like this whole store-multiple-LSNs
> > thing is too much. We can still do block-level in
On Tue, Aug 5, 2014 at 06:36:01PM -0700, Josh Berkus wrote:
> On 08/05/2014 06:25 PM, Alvaro Herrera wrote:
>
> > I'm not sold on += as the syntax to use. It just needs to be something
> > different from =.
>
> Alternative is to use "+" in the value string:
>
> shared_preload_libraries = '+au
On Tue, Aug 5, 2014 at 07:22:13PM -0600, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Aug 5, 2014 at 12:52:51PM -0700, Josh Berkus wrote:
> >> However, other than shared_preload_libraries, I can't think of a GUC
> >> which would benefit from this. Can you?
>
> > search_path?
>
> Given
I've looked at another (admittedly sympathetic) dataset that is
publicly available: the flickr "tags" dataset [1]. I end up with a
single table of tags; it's a large enough table, at 388 MB, but the
tuples are not very wide. There are 7,656,031 tags/tuples.
Predictably enough, this query is very f
FWIW I think I haven't responded appropriately to the points raised by
Heikki. Basically, as I see it there are three main items:
1. the revmap physical-to-logical mapping is too complex; let's use
something else.
We had revmap originally in a separate fork. The current approach grew
out of the
土卜皿 wrote:
> 2014-08-05 22:08 GMT+08:00 土卜皿 :
>
> > hi, all
> > I already can debug general postgres using "ddd" and "select
> > pg_backend_pid();" , now, I want to study the details of the system
> > catalog cache and system cache management, so I need to debug the function
> > InitPostgres()
On Tue, Aug 5, 2014 at 10:55 PM, Tom Lane wrote:
> Josh Berkus writes:
> > BTW, while there's unlikely to be a good reason to put search_path in
> > pg.conf with appends, there are a LOT of reasons to want to be able to
> > append to it during a session.
>
> [shrug...] You can do that today wit
On Tue, Aug 05, 2014 at 07:32:35PM -0700, Peter Geoghegan wrote:
> select * from (select * from tags order by tag offset 1) ii;
>
> Git master takes about 25 seconds to execute the query. Patched takes
> about 6.8 seconds. That seems very good, but this is not really new
> information.
>
On Tue, Aug 5, 2014 at 8:55 PM, Noah Misch wrote:
> Comparator cost affects external sorts more than it affects internal sorts.
> When I profiled internal and external int4 sorting, btint4cmp() was 0.37% of
> the internal sort profile and 10.26% of the external sort profile.
Did you attempt to ch
On Tue, Aug 05, 2014 at 09:32:59PM -0700, Peter Geoghegan wrote:
> On Tue, Aug 5, 2014 at 8:55 PM, Noah Misch wrote:
> > Comparator cost affects external sorts more than it affects internal sorts.
> > When I profiled internal and external int4 sorting, btint4cmp() was 0.37% of
> > the internal sor
> >> I have improved the patch by making following changes:
> >>
> >> 1. Since stream_stop() was redundant, stream_stop() at the time of
> WAL file closing was deleted.
> >>
> >> 2. Change the Flash judging timing for the readability of source code.
> >>I have changed the Flash judging timing
On 6 August 2014 03:16, Bruce Momjian wrote:
> On Wed, Aug 6, 2014 at 09:17:35AM +0900, Michael Paquier wrote:
>> On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
>> >
>> > On 5 August 2014 22:38, Claudio Freire wrote:
>> > Thinking some more, there seems like this whole store-multiple-LSNs
>
On Tue, Aug 5, 2014 at 12:49 PM, Fujii Masao wrote:
> On Mon, Aug 4, 2014 at 11:52 PM, Tom Lane wrote:
>> Fujii Masao writes:
>>> The patch chooses the last settings for every parameters and ignores the
>>> former settings. But I don't think that every parameters need to be
>>> processed
>>> th
Hello Robert,
The issue is that there are 3 definitions of modulo, two of which are fine
(Knuth floored division and Euclidian), and the last one much less useful.
Alas, C (%) & SQL (MOD) choose the bad definition:-( I really need any of
the other two. The attached patch adds all versions, with
Hello Alvaro,
I wonder if it would be necessary to offer the division operator
semantics corresponding to whatever additional modulo operator we choose
to offer. That is, if we add emod, do we need "ediv" as well?
I would make sense, however I do not need it, and I'm not sure of a use
case
On Wed, Aug 6, 2014 at 2:34 PM, wrote:
>> >> I have improved the patch by making following changes:
>> >>
>> >> 1. Since stream_stop() was redundant, stream_stop() at the time of
>> WAL file closing was deleted.
>> >>
>> >> 2. Change the Flash judging timing for the readability of source code.
>
On Wed, Aug 6, 2014 at 4:47 AM, Robert Haas wrote:
> On Mon, Aug 4, 2014 at 11:35 AM, Manuel Kniep wrote:
>> I’m missing the PG_RETURN_UINT16 macro in fmgr.h
>> Since we already have the PG_GETARG_UINT16 macro
>> I guess it makes sense to to have it.
>>
>> here is the trivial patch for it.
>
> I
For example, if we had reason to be concerned about *adversarial*
inputs, I think that there is a good chance that our qsort() actually
would be problematic to the point of driving us to prefer some generally
slower alternative.
That is an interesting point.
Indeed, a database in general of
On Tue, Aug 5, 2014 at 11:49 PM, Fabien COELHO wrote:
> If so, adding some randomness in the decision process would suffice to
> counter the adversarial input argument you raised.
This is specifically addressed by the paper. Indeed, randomly choosing
a pivot is a common strategy. It won't fix th
70 matches
Mail list logo
