On Fri, March 28, 2014 09:31, Heikki Linnakangas wrote:
> I went back and tried Erik's original test
> (http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl).
> With a fresh checkout from master, the difference between the slow and
> fast queries is much
Merlin Moncure writes:
> Trying to follow along here. Am I correct in saying that if you make
> these changes any SQL level functionality (say, creating a composite
> type containing a large array) that used to work will continue to
> work?
This wouldn't change any SQL-level functionality ... as
On Fri, Mar 28, 2014 at 3:34 PM, Tom Lane wrote:
> Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
> we established a coding rule that it was okay for composite Datums
> to contain external (out-of-line) toasted fields, as long as such
> toasting didn't go more than one level deep
Andres Freund writes:
> I don't think it's necessary. As far as I understand LATERAL, a join to
> a function returning NULL will still return the row. So, the test now
> would only test whether there are rows in pg_class which seems a bit
> pointless.
Yeah, after looking closer I'd come to the sa
On 2014-03-28 16:45:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
> >> Any objection to separating out the have_mappings bit? It wasn't terribly
> >> appropriate before, but it seems really out of place in this formulation.
>
> > The patch I
Andres Freund writes:
> On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
>> Any objection to separating out the have_mappings bit? It wasn't terribly
>> appropriate before, but it seems really out of place in this formulation.
> The patch I sent removed the have_mapping thing entirely? Do you mean
On 2014-03-28 16:41:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
> >> Buildfarm member prairiedog thinks there's something unreliable about
> >> commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
>
> > That's rather odd. It has survived for a c
Andres Freund writes:
> On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
>> Buildfarm member prairiedog thinks there's something unreliable about
>> commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
> That's rather odd. It has survived for a couple of months on the other
> buildfarm animals now... Co
David Fetter writes:
> On Fri, Mar 28, 2014 at 03:50:10PM +, Tom Lane wrote:
>> Fix EquivalenceClass processing for nested append relations.
> If this is a bug fix, shouldn't it be back-patched?
It's a planner improvement; it's not a bug fix in the sense that previous
plans were wrong. We t
Hi,
On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
> Buildfarm member prairiedog thinks there's something unreliable about
> commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
> ***
> /Users/buildfarm/bf-data/HEAD/pgsql.13462/src/test/regress/expected/alter_table.out
>Thu Mar 27 04:12:40 20
Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
we established a coding rule that it was okay for composite Datums
to contain external (out-of-line) toasted fields, as long as such
toasting didn't go more than one level deep in any tuple. This meant
that heap_form_tuple had to go
On Fri, Mar 28, 2014 at 03:50:10PM +, Tom Lane wrote:
> Fix EquivalenceClass processing for nested append relations.
If this is a bug fix, shouldn't it be back-patched?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfet
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
> >> I believe Bruce was suggesting to show it when it is set to *not* the
> >> default, which strikes me as perfectly reasonable.
>
> > We seem to be split on the ide
On Fri, Mar 28, 2014 at 3:41 PM, Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
> >> I believe Bruce was suggesting to show it when it is set to *not* the
> >> default, which strikes me as perfectly reasonable.
>
> > We seem to be spli
Bruce Momjian writes:
> On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
>> I believe Bruce was suggesting to show it when it is set to *not* the
>> default, which strikes me as perfectly reasonable.
> We seem to be split on the idea of having "Has OIDs" display only when
> the oid
On Thu, Mar 27, 2014 at 02:54:26PM -0400, Stephen Frost wrote:
> * Euler Taveira (eu...@timbira.com.br) wrote:
> > On 27-03-2014 10:15, Bruce Momjian wrote:
> > > When we made OIDs optional, we added an oid status display to \d+:
> > >
> > > test=> \d+ test
> > >Table
I wrote:
> Honza writes:
>> after a months I've found a time to make test-case for this bug, probably:
> Confirmed that this reproduces a problem on HEAD. Will look into it,
> thanks!
I believe I understand what's going on here, and it's not quite as
exciting as it first appears. The issue is
Hello. I've been doing some benchmarks on performance / size differences
between actions when wal_level is set to either archive or hot_standby. I'm
not seeing a ton of difference. I've read some posts about discussions as
to whether this parameter should be simplified and remove or merge these
On Fri, Mar 28, 2014 at 5:57 AM, Michael Paquier
wrote:
> What about the overhead that this processing creates if error
> processing needs to scan a schema with let's say hundreds of tables?
It doesn't work that way. I've extended searchRangeTableForCol() so
that when it calls scanRTEForColumn(),
Tom Lane wrote:
> Alvaro Herrera writes:
> > My proposal therefore is to add some more columns to
> > pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
> > which would carry exactly what get_object_address() would require to
> > re-construct an ObjectAddress for the object b
Hackers,
after reading Heikki Linnakangas presentation about GIN from Nordic PGDay,
I figure out that btree_gin became much more attractive.
http://hlinnaka.iki.fi/presentations/NordicPGDay2014-GIN.pdf
But it have one weird behaviour: when you have range restriction like "col
> const1 AND col < c
Alvaro Herrera writes:
> My proposal therefore is to add some more columns to
> pg_event_trigger_dropped_objects(): more precisely, objname and objargs,
> which would carry exactly what get_object_address() would require to
> re-construct an ObjectAddress for the object being dropped at the remote
Honza writes:
> after a months I've found a time to make test-case for this bug, probably:
Confirmed that this reproduces a problem on HEAD. Will look into it,
thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 03/28/2014 04:30 PM, Alexander Korotkov wrote:
> We have range types, and restriction "col <@ range" can be correctly
> handled by gin_extract_query, because it will be passed there as single
> restriction. This is workaround itself, but it's weird to force users
> express queries like this.
T
Hi,
after a months I've found a time to make test-case for this bug, probably:
I've got my custom type and a table stores historical data of the main table.
The problem occurs at our production servers, version 9.2.6. We've found it
after our backups wasn't
complete because of selection from "c
Kyotaro HORIGUCHI writes:
> Hello. Attached is the 2nd version of 'pushdown in UNION ALL on
> partitioned tables' patch type 1 - fix in equiv-member version.
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
As you probably know, I've studying how to implement a system to allow
replicating DDL commands to remote servers. I have a fairly good grasp
of handling CREATE commands; we have another thread discussing that
involving a JSON output for such commands. That hasn't been carried to
completion yet;
On Fri, Mar 28, 2014 at 4:10 AM, Peter Geoghegan wrote:
> With the addition of LATERAL subqueries, Tom fixed up the mechanism
> for keeping track of which relations are visible for column references
> while the FROM clause is being scanned. That allowed
> errorMissingColumn() to give a more useful
Re: Albe Laurenz 2014-03-28
> > ERROR: 42703: column ol.orderids does not exist
> > LINE 1: ...* from orders o join orderlines ol on o.orderid = ol.orderid...
> > ^
> > HINT: Perhaps you meant to reference the column "ol"."orderid".
>
Peter Geoghegan wrote:
> With the addition of LATERAL subqueries, Tom fixed up the mechanism
> for keeping track of which relations are visible for column references
> while the FROM clause is being scanned. That allowed
> errorMissingColumn() to give a more useful error to the one produced
> by th
Very interesting idea, I'd think about optionally add similarity hinting
support to psql tab. With, say, 80% of similarity matching, it
shouldn't be very annoying. For interactive usage there is no risk of
slowdown.
On Mar 27, 2014 11:11 PM, "Peter Geoghegan" wrote:
> With the addition of
I went back and tried Erik's original test
(http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl).
With a fresh checkout from master, the difference between the slow and
fast queries is much less dramatic than Erik reported. The reason is
that Alexand
2014-03-28 9:22 GMT+01:00 Peter Geoghegan :
> On Fri, Mar 28, 2014 at 1:00 AM, Pavel Stehule
> wrote:
> > I see only one risk - it can do some slowdown of exception processing.
>
> I think it's unlikely that you'd see ERRCODE_UNDEFINED_COLUMN in
> procedural code like that in practice. In any cas
On Fri, Mar 28, 2014 at 1:00 AM, Pavel Stehule wrote:
> I see only one risk - it can do some slowdown of exception processing.
I think it's unlikely that you'd see ERRCODE_UNDEFINED_COLUMN in
procedural code like that in practice. In any case it's worth noting
that I continually pass back a "max"
Hello
I see only one risk - it can do some slowdown of exception processing.
Sometimes you can have a code like
BEGIN
WHILE ..
LOOP
BEGIN
INSERT INTO ...
EXCEPTION WHEN ..
; /* ignore this error */
END;
END LOOP;
without this risks, proposed feature is nice, but sh
On 27 March 2014 21:01, Florian Pflug wrote:
> First, sorry guys for letting this slide - I was overwhelmed by other works,
> and this kind of slipped my mind :-(
>
> On Mar27, 2014, at 09:04 , Dean Rasheed wrote:
>> On 26 March 2014 19:43, David Rowley wrote:
>>> On Thu, Mar 27, 2014 at 7:33 AM
36 matches
Mail list logo
