2012/10/25 Kevin Grittner :
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>> > Pavel Stehule wrote:
>> >> 2012/10/22 Tom Lane :
>> >>> Perhaps it would be close enough to what you want to use DISTINCT ON:
>> >>> contrib_regression=# explain select distinct on( t <-> 'foo') *,t <->
>> >>> 'foo' fr
Hi All,
Query with the sub-query in the projection list ending up with hitting all
the
partition table even though having proper partition key condition.
Example:
CREATE TABLE measurement (
city_id int not null,
logdate date not null,
peaktempint,
unitsale
On 10/26/2012 1:29 AM, Amit Kapila wrote:
On Thursday, October 25, 2012 9:46 PM Jan Wieck wrote:
On 10/25/2012 10:12 AM, Stephen Frost wrote:
> Jan,
>
> * Jan Wieck (janwi...@yahoo.com) wrote:
>> The problem case this patch is dealing with is rolling window tables
>> that experienced some bloat.
On Thursday, October 25, 2012 9:46 PM Jan Wieck wrote:
> On 10/25/2012 10:12 AM, Stephen Frost wrote:
> > Jan,
> >
> > * Jan Wieck (janwi...@yahoo.com) wrote:
> >> The problem case this patch is dealing with is rolling window tables
> >> that experienced some bloat. The typical example is a log tab
> On Sat, Oct 20, 2012 at 9:49 PM, Daniel Farina wrote:
>>
>> An unrelated defect, although the patch tries to carefully clean up
>> the 'res' result from psqlexec in the error cases, it does forget to
>> do that, seemingly, in the 'positive' case, while it is looping. I
>> think it needs another
On Oct 25, 2012, at 5:07 PM, Peter Eisentraut wrote:
> I think the emerging standard is to have a README.md (or something
> similar). This gives enough structure and formatting options for most
> extensions.
For PGXN, I have used a README.md for a readme (briefly about the extension,
how to bu
On Thu, 2012-10-25 at 10:31 -0700, David E. Wheeler wrote:
> Any plans to implement a documentation standard for extensions? I would love
> to see `make install` create the necessary man pages and perhaps even HTML
> (with a link added in the proper place). Anyone given this any thought? Dim?
I
On 25-10-2012 21:05, David Johnston wrote:
> If this is the case does pg_upgrade "init-db" for this purpose?
>
Yes.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mai
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Euler Taveira
> Sent: Thursday, October 25, 2012 6:59 PM
> To: Erik Rijkers
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] sql_implementation_info still c
On 25-10-2012 15:36, Erik Rijkers wrote:
> I would expect 9.2.1 to contain '09.02.0001' (not '09.02.').
>
'09.02.' is the initdb'ed version. It seems you upgrade binaries from 9.2
to 9.2.1.
euler=# select version();
version
-
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Pavel Stehule wrote:
> >> 2012/10/22 Tom Lane :
> >>> Perhaps it would be close enough to what you want to use DISTINCT ON:
> >>> contrib_regression=# explain select distinct on( t <-> 'foo') *,t <->
> >>> 'foo' from test_trgm order by t <-> 'foo' li
On Oct 25, 2012, at 10:42 AM, Simon Riggs wrote:
>> Any plans to implement a documentation standard for extensions? I would love
>> to see `make install` create the necessary man pages and perhaps even HTML
>> (with a link added in the proper place). Anyone given this any thought? Dim?
>
> Isn
On 10/25/2012 12:24 PM, Alvaro Herrera wrote:
Jan Wieck wrote:
In the original code, the maximum delay that autovacuum can cause by
holding the exclusive lock is one deadlock_timeout (default 1s). It
would appear reasonable to me to use max(deadlock_timeout/10,10ms)
as the interval to check for
On 25 October 2012 19:31, David E. Wheeler wrote:
> Hackers,
>
> Any plans to implement a documentation standard for extensions? I would love
> to see `make install` create the necessary man pages and perhaps even HTML
> (with a link added in the proper place). Anyone given this any thought? Dim
I noticed this in information_schema; it would seem
the 'DBMS VERSION' is still the old value:
$ psql
psql (9.2.1)
Type "help" for help.
# select version();
version
---
PostgreS
Hackers,
Any plans to implement a documentation standard for extensions? I would love to
see `make install` create the necessary man pages and perhaps even HTML (with a
link added in the proper place). Anyone given this any thought? Dim?
Thanks,
David
--
Sent via pgsql-hackers mailing list (
"Kevin Grittner" writes:
> Pavel Stehule wrote:
>> 2012/10/22 Tom Lane :
>>> Perhaps it would be close enough to what you want to use DISTINCT ON:
>>> contrib_regression=# explain select distinct on( t <-> 'foo') *,t <-> 'foo'
>>> from test_trgm order by t <-> 'foo' limit 10;
>> good tip - it's
I wrote:
> The fact that SEQUENCE SET is considered pre-data has bitten us several
> times already, eg
> http://archives.postgresql.org/pgsql-bugs/2012-05/msg00084.php
> I think it may be time to bite the bullet and change that (including
> breaking dumpSequence() into two separate functions). I'
Pavel Stehule wrote:
> 2012/10/22 Tom Lane :
>> Perhaps it would be close enough to what you want to use DISTINCT ON:
>>
>> contrib_regression=# explain select distinct on( t <-> 'foo') *,t <-> 'foo'
>> from test_trgm order by t <-> 'foo' limit 10;
> good tip - it's working
If two or more value
Jan Wieck wrote:
> In the original code, the maximum delay that autovacuum can cause by
> holding the exclusive lock is one deadlock_timeout (default 1s). It
> would appear reasonable to me to use max(deadlock_timeout/10,10ms)
> as the interval to check for a conflicting lock request. For another
After some fooling around to provide the discussed backend functionality
to xlogdump (StringInfo atop PQExpBuffer and elog_start/elog_finish),
the following items still need work:
1. rmgr tables
We're linking rmgr.c so that we can obtain the appropriate rm_desc
function pointer for each rmgr. How
On 10/25/2012 10:12 AM, Stephen Frost wrote:
Jan,
* Jan Wieck (janwi...@yahoo.com) wrote:
The problem case this patch is dealing with is rolling window tables
that experienced some bloat. The typical example is a log table,
that has new data constantly added and the oldest data constantly
purge
> Naturally, there are other compression and delta encoding schemes. Does
> anyone feel the need to explore further alternatives?
>
> We might eventually find the need for multiple, user-selectable, WAL
> compression strategies. I don't recommend taking that step yet.
>
my currently implement
2012/10/25 Tom Lane :
> Pavel Stehule writes:
>> 2012/10/25 Tom Lane :
>>> Personally I saw no reason for this patch to touch psqlscan.l in the
>>> first place. Commands such as \set just scan variable names with
>>> psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
>
>> it cann
Pavel Stehule writes:
> 2012/10/25 Tom Lane :
>> Personally I saw no reason for this patch to touch psqlscan.l in the
>> first place. Commands such as \set just scan variable names with
>> psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
> it cannot be same, because current sc
2012/10/25 Tom Lane :
> Alvaro Herrera writes:
>> I gave this a look. I think it needs to be revised by somebody with a
>> better understanding of scanner (flex) than me, but I didn't like the
>> changes in psqlscan.l at all; the new pattern is too unlike the
>> rest of the surrounding patterns,
Dimitri Fontaine writes:
> Alvaro Herrera writes:
>> No, just remove the RELKIND_UNCATALOGUED case in that switch.
> Oh. As in the attached? :)
I don't think you tested this patch in 9.2 or HEAD, because it bleats
like mad. I installed an extension containing
create sequence extseq;
select p
Alvaro Herrera wrote:
> Kevin Grittner escribió:
>> Tom Lane wrote:
>
>>> Also, it doesn't appear that we ever got around to preparing
>>> documentation updates, but I think we definitely need some if
>>> we're going to start throwing errors for things that used to be
>>> allowed. Since Kevin has
> Comments about the approach or even the general direction of the
> implementation? Questions?
This patch series has gotten serious amount of discussion and useful
feedback; even some parts of it have been committed. I imagine lots
more feedback, discussion and spawning of new ideas will take p
Tom Lane escribió:
> Alvaro Herrera writes:
> > I gave this a look. I think it needs to be revised by somebody with a
> > better understanding of scanner (flex) than me, but I didn't like the
> > changes in psqlscan.l at all; the new pattern is too unlike the
> > rest of the surrounding patterns
Alvaro Herrera writes:
> I gave this a look. I think it needs to be revised by somebody with a
> better understanding of scanner (flex) than me, but I didn't like the
> changes in psqlscan.l at all; the new pattern is too unlike the
> rest of the surrounding patterns, and furthermore it has been
I gave this a look. I think it needs to be revised by somebody with a
better understanding of scanner (flex) than me, but I didn't like the
changes in psqlscan.l at all; the new pattern is too unlike the
rest of the surrounding patterns, and furthermore it has been placed
within the block that sa
Jan,
* Jan Wieck (janwi...@yahoo.com) wrote:
> The problem case this patch is dealing with is rolling window tables
> that experienced some bloat. The typical example is a log table,
> that has new data constantly added and the oldest data constantly
> purged out. This data normally rotates throug
On 10/25/2012 9:45 AM, Tom Lane wrote:
Jan Wieck writes:
On 10/24/2012 10:46 PM, Stephen Frost wrote:
Would it be possible to use the FSM to figure out if things have changed
since the last scan..? Does that scan update the FSM, which would then
be updated by another backend in the event that
Alvaro Herrera writes:
> The other one was reported by Marko Kreen in
> http://archives.postgresql.org/message-id/cacmqxcjjauc9jpa64vxskrn67byjuymodz-mgy-_aoz6erg...@mail.gmail.com
> (the thread talks about 2 bugs, but one of them is just pilot error).
> Dimitri posted patches to the real bug for
Jan Wieck writes:
> On 10/24/2012 10:46 PM, Stephen Frost wrote:
>> Would it be possible to use the FSM to figure out if things have changed
>> since the last scan..? Does that scan update the FSM, which would then
>> be updated by another backend in the event that it decided to write
>> somethin
We have a couple of unfixed bugs regarding extensions, for which patches
have been proposed but remain unfixed in git.
The oldest is bug #6704, for which a proposed fix for the master branch
was posted here:
http://archives.postgresql.org/message-id/m2zk4e6p7m@2ndquadrant.fr
There was some di
> WAL-only tables/queues "prohobit" none of what you claim above, you just
> implement in a (loosely) MVCC way by keeping track of what events are
> processed.
Well, per our discussion here in person, I'm not convinced that this
buys us anything in the "let's replace AMQ" case. However, as I poi
Steven,
On 10/24/2012 10:46 PM, Stephen Frost wrote:
Jan,
* Jan Wieck (janwi...@yahoo.com) wrote:
This problem has been discussed before. Those familiar with the
subject please skip the next paragraph.
Apologies if this was already thought-of and ruled out for some reason,
but...
Because a
On 24 October 2012 21:44, Alvaro Herrera wrote:
> Here's a small WIP patch that does the proposed splitting. This is a
> first step towards the objective of having a separately compilable
> xlogdump -- more work is needed before that can be made to work fully.
>
> Now, per previous discussion, I
40 matches
Mail list logo
