Hello Heikki,
A couple of comments:
* There should be an explicit "\setrandom ... uniform" option too, even
though you get that implicitly if you don't specify the distribution
Indeed. I agree. I suggested it, but it got lost.
* What exactly does the "threshold" mean? The docs informally e
On Fri, Mar 14, 2014 at 6:44 PM, Tomas Vondra wrote:
> Well, depends on how you define useful. With the sample dataset
> 'delicious' (see Peter's post) I can do this:
>
>SELECT doc FROM delicious
> WHERE doc @> '{"title_detail" : {"value" : "TheaterMania"}}';
>
> with arbitrary paths
On 03/14/2014 06:44 PM, Tomas Vondra wrote:
> Stupid question - so if I have a json like this:
Not a stupid question, actually. In fact, I expect to answer it 400 or
500 times over the lifespan of 9.4.
> { "a" : { "b" : "c"}}
>
> the GIN code indexes {"b" : "c"} as a single value? And then t
On 15.3.2014 02:03, Greg Stark wrote:
> On Fri, Mar 14, 2014 at 9:21 PM, Tomas Vondra wrote:
>> I'm not awfully familiar with the GIN code, but based on Alexander's
>> feedback I presume fixing the GIN length limit (or rather removing it,
>> as it's a feature, not a bug) is quite straightforward.
On Fri, Mar 14, 2014 at 5:10 PM, Tomas Vondra wrote:
> I'm on commit a3115f0d, which is just 2 days old, so I suppose this was
> not fixed yet.
Try merging the feature branch now, which will get you commit 16923d,
which you're missing. That was an open item for a while, which I only
got around to
On Fri, Mar 14, 2014 at 9:21 PM, Tomas Vondra wrote:
> I'm not awfully familiar with the GIN code, but based on Alexander's
> feedback I presume fixing the GIN length limit (or rather removing it,
> as it's a feature, not a bug) is quite straightforward. Why not to at
> least consider that for 9.4
On 2014-03-14 22:21:18 +0100, Tomas Vondra wrote:
> Don't get me wrong - I'm aware it's quite late in the last commitfest,
> and if it's deemed unacceptable / endandering 9.4 release, I'm not going
> to say a word. But if it's a simple patch ...
IMNSHO there's no bloody chance for such an addition
On 14.3.2014 23:06, Peter Geoghegan wrote:
> For the benefit of anyone that would like to try the patch out, I make
> available a custom format dump of some delicious sample data. I can
> query the sample data as follows on my local installation:
>
> [local]/jsondata=# select count(*) from delicio
On 14.3.2014 22:54, Peter Geoghegan wrote:
> On Fri, Mar 14, 2014 at 2:21 PM, Tomas Vondra wrote:
>> I'm not awfully familiar with the GIN code, but based on Alexander's
>> feedback I presume fixing the GIN length limit (or rather removing it,
>> as it's a feature, not a bug) is quite straightforw
For the benefit of anyone that would like to try the patch out, I make
available a custom format dump of some delicious sample data. I can
query the sample data as follows on my local installation:
[local]/jsondata=# select count(*) from delicious ;
count
-
1079399
(1 row)
[local]/json
On Fri, Mar 14, 2014 at 2:21 PM, Tomas Vondra wrote:
> I'm not awfully familiar with the GIN code, but based on Alexander's
> feedback I presume fixing the GIN length limit (or rather removing it,
> as it's a feature, not a bug) is quite straightforward. Why not to at
> least consider that for 9.4
On 14.3.2014 20:18, Josh Berkus wrote:
> On 03/14/2014 04:52 AM, Oleg Bartunov wrote:
>> VODKA index will have no lenght limitation.
>
> Yeah, so I think we go with what we have, and tell people "if you're
> hitting these length issues, wait for 9.5, where they will be
> fixed."
VODKA may be gre
Josh Berkus wrote:
> Alvaro, All:
>
> Can someone help me with what we should tell users about this issue?
>
> 1. What users are especially likely to encounter it? All replication
> users, or do they have to do something else?
Replication users are more likely to get it on replicas, of course,
Whilst setting up a buildfarm member on an old, now-spare Mac, I was
somewhat astonished to discover that contrib/test_shm_mq crashes thus:
TRAP: FailedAssertion("!(rb >= sizeof(uint64))", File: "shm_mq.c", Line: 429)
but only in UTF8 locales, not in C locale. You'd have bet your last
dollar that
On 03/14/2014 12:45 PM, Oleg Bartunov wrote:
> 9.5 may too optimistic :)
Nonsense, you, Teodor and Alexander are geniuses. It can't possibly
take you more than a year. ;-)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On 15/03/14 08:45, Oleg Bartunov wrote:
9.5 may too optimistic :)
On Fri, Mar 14, 2014 at 11:18 PM, Josh Berkus wrote:
On 03/14/2014 04:52 AM, Oleg Bartunov wrote:
VODKA index will have no lenght limitation.
Yeah, so I think we go with what we have, and tell people "if you're
hitting these l
On Mon, Mar 10, 2014 at 3:16 PM, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-02-16 21:26:47 -0500, Robert Haas wrote:
>
> >> I don't really know about cpu_tuple_cost. Kevin's often
> >> advocated raising it, but I haven't heard anyone else advocate
> >> for that. I think we need da
Alvaro, All:
Can someone help me with what we should tell users about this issue?
1. What users are especially likely to encounter it? All replication
users, or do they have to do something else?
2. What error messages will affected users get? A link to the reports
of this issue on pgsql lists
9.5 may too optimistic :)
On Fri, Mar 14, 2014 at 11:18 PM, Josh Berkus wrote:
> On 03/14/2014 04:52 AM, Oleg Bartunov wrote:
>> VODKA index will have no lenght limitation.
>
> Yeah, so I think we go with what we have, and tell people "if you're
> hitting these length issues, wait for 9.5, where
On 03/14/2014 04:52 AM, Oleg Bartunov wrote:
> VODKA index will have no lenght limitation.
Yeah, so I think we go with what we have, and tell people "if you're
hitting these length issues, wait for 9.5, where they will be fixed."
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
On 03/14/2014 01:03 PM, Peter Geoghegan wrote:
Ping?
I committed the other patch this depends on now. I'll take another stab
at this one next.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On Fri, Mar 14, 2014 at 12:00 PM, Alvaro Herrera
wrote:
> I don't think we should be worried about there being a lot of extra code
> to write as DDL is added or modified. I do share your concern that
> we're going to *forget* to write these things in the first place, unless
> we do something to a
Robert Haas wrote:
> What does the colon-space in %{definition: }s mean?
It means it expects the "definition" element to be a JSON array, and
that it will format the elements by separating them with a space. In
other DDL commands, there are things like %{table_element:, }s which
means to sepa
On Tue, Mar 11, 2014 at 1:24 PM, Parul Lakkad wrote:
> I am trying to figure out when disk is used to store intermediate results
> while performing joins in postgres.
Joins can also cause a Nested Loop+Materialize plan, which spills to
disk if the materialize result set is too large for work_mem.
After some discussion, the core committee has concluded that the
WAL-replay bug fixed in commit 6bfa88acd3df830a5f7e8677c13512b1b50ae813
is indeed bad enough to justify near-term update releases. Since
there seems no point in being slow about it, tarballs will be wrapped
Monday (3/17) for public a
On Thu, Mar 13, 2014 at 5:06 PM, Alvaro Herrera
wrote:
> Alvaro Herrera escribió:
>
>> I also fixed the sequence OWNED BY problem simply by adding support for
>> ALTER SEQUENCE. Of course, the intention is that all forms of CREATE
>> and ALTER are supported, but this one seems reasonable standalo
2014-03-14 13:12 GMT+01:00 Simon Riggs :
> On 14 March 2014 11:10, Pavel Stehule wrote:
> >
> >
> >
> > 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja :
> >
> >> On 3/14/14 10:56 AM, Simon Riggs wrote:
> >>>
> >>> The patch looks fine, apart from some non-guideline code formatting
> >>> issues.
> >>
>
Umm.. Sorry for repeated correction.
2014/03/14 21:12 "Kyotaro HORIGUCHI" :
>
> Ah, ok. I understood what you meant.
> Sorry that I can't confirm rihgt now, the original issue should occur on
the standby.
The original issue should have occurred on standby
> I might've oversimplicated.
>
> regard
On 14 March 2014 11:10, Pavel Stehule wrote:
>
>
>
> 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja :
>
>> On 3/14/14 10:56 AM, Simon Riggs wrote:
>>>
>>> The patch looks fine, apart from some non-guideline code formatting
>>> issues.
>>
>>
>> I'm not sure what you're referring to. I thought it looked
Hello,
2014/03/14 20:51 "Heikki Linnakangas" :
> You created recovery.conf in the master server after crash. Just don't do
that.
Ah, ok. I understood what you meant.
Sorry that I can't confirm rihgt now, the original issue should occur on
the standby. I might've oversimplicated.
regards,
--
Kyo
VODKA index will have no lenght limitation.
On Fri, Mar 14, 2014 at 3:07 PM, Tomas Vondra wrote:
> On 13 Březen 2014, 23:39, Peter Geoghegan wrote:
>> On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark wrote:
>>> It does sound like the main question here is which opclass should be
>>> the default. From
On 03/14/2014 01:24 PM, Kyotaro HORIGUCHI wrote:
Hmm.. What I did is simplly restarting server just after a crash but the
server was accidentially in backup mode. No backup copy is used. Basically,
the server is in the same situation with the simple restart after crash.
You created recovery.co
On 03/13/2014 04:00 PM, Fujii Masao wrote:
On Thu, Mar 13, 2014 at 10:51 PM, Heikki Linnakangas
wrote:
IMHO we should just implement the \setrandom changes, and not add any of
these options to modify the standard test workload. If someone wants to run
TPC-B workload with gaussian or exponential
Sorry, I wrote a little wrong.
2014/03/14 20:24 "Kyotaro HORIGUCHI" :
> I wish to save the database for the case and I suppose it so acceptable.
and I don't suppose it so unacceptable.
regards,
--
Kyotaro Horiguchi
NTT Opensource Software Center
Thank you.
2014/03/14 19:42 "Heikki Linnakangas" :
>
> On 03/14/2014 12:32 PM, Kyotaro HORIGUCHI wrote:
>>
>> Restarting server with archive recovery fails as following just
>> after it was killed with SIGKILL after pg_start_backup and some
>> wal writes but before pg_stop_backup.
>>
>> | FATAL:
2014-03-14 12:02 GMT+01:00 Marko Tiikkaja :
> On 3/14/14 10:56 AM, Simon Riggs wrote:
>
>> The patch looks fine, apart from some non-guideline code formatting
>> issues.
>>
>
> I'm not sure what you're referring to. I thought it looked fine.
>
>
> Having looked at gcc and clang, I have a proposa
On 13 Březen 2014, 23:39, Peter Geoghegan wrote:
> On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark wrote:
>> It does sound like the main question here is which opclass should be
>> the default. From the discussion there's a jsonb_hash_ops which works
>> on all input values but supports fewer operators
Ping?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/14/14 10:56 AM, Simon Riggs wrote:
The patch looks fine, apart from some non-guideline code formatting issues.
I'm not sure what you're referring to. I thought it looked fine.
Having looked at gcc and clang, I have a proposal for naming/API
We just have two variables
plpgsql.compil
On 03/14/2014 12:32 PM, Kyotaro HORIGUCHI wrote:
Restarting server with archive recovery fails as following just
after it was killed with SIGKILL after pg_start_backup and some
wal writes but before pg_stop_backup.
| FATAL: WAL ends before end of online backup
| HINT: Online backup started with
On Fri, Mar 14, 2014 at 6:30 AM, Prabakaran, Vaishnavi <
vaishna...@fast.au.fujitsu.com> wrote:
> Hi,
>
>
>
> In connection to my previous proposal about "providing catalog view to
> pg_hba.conf file contents" , I have developed the attached patch .
>
>
>
> [Current situation]
>
> Currently, to vi
Hello, we found that postgreql won't complete archive recovery
foever on some situation. This occurs HEAD, 9.3.3, 9.2.7, 9.1.12.
Restarting server with archive recovery fails as following just
after it was killed with SIGKILL after pg_start_backup and some
wal writes but before pg_stop_backup.
|
On 3 February 2014 20:17, Pavel Stehule wrote:
> Hello
>
> I am not happy from "warnings_as_error"
>
> what about "stop_on_warning" instead?
>
> second question: should be these errors catchable or uncatchable?
>
> When I work on large project, where I had to use some error handler of
> "EXCEPTION
On Fri, Mar 14, 2014 at 12:29 PM, Tanmay Deshpande
wrote:
> My doubt is when the query enters into a portal, does it stay in the portal
> till the final execution ?
Yes, portal represents the execution state of query, after the
optimizer creates the
plan, portal is used in execution of query.
W
On Fri, Mar 14, 2014 at 12:29 PM, Tanmay Deshpande wrote:
> My doubt is when the query enters into a portal, does it stay in the
> portal till the final execution ? i.e. Do the further function calls such
> as DefineRelation,create_heap_with_catalog etc. for Create query occur
> inside the portal
Well, when we set '--gaussian=NUM' or '--exponential=NUM' on command line, we
can see access probability of top N records in result of final output. This
out put is under following,
Indeed. I had forgotten this point. This is a significant information that
I would not like to loose.
This f
My doubt is when the query enters into a portal, does it stay in the portal
till the final execution ? i.e. Do the further function calls such as
DefineRelation,create_heap_with_catalog etc. for Create query occur inside
the portal ?
47 matches
Mail list logo
