On Wed, Feb 29, 2012 at 06:22:27PM -0500, A.M. wrote:
>
> On Feb 29, 2012, at 6:02 PM, Bruce Momjian wrote:
>
> > On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote:
> >> On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian wrote:
> >>> OK, I have implemented both Roberts and Àlvaro's ideas i
On Thu, Mar 1, 2012 at 4:13 AM, Alvaro Herrera
wrote:
>
> Excerpts from Heikki Linnakangas's message of jue ene 26 15:58:58 -0300 2012:
>> On 26.01.2012 17:31, Tom Lane wrote:
>
>> > The idea that occurs to me is to have the code that uses the GUC do a
>> > verify_mbstr(noerror) on it, and silentl
Jim Nasby writes:
> On 2/29/12 3:53 PM, Alvaro Herrera wrote:
>> .. in fact this is precisely what killed Zdenek Kotala's idea of
>> upgrading.
> This is also why Simon has avoided the whole upgrade thing with his 16 bit
> checksum idea (otherwise presumably we'd be looking at bigger checksums
I'm curious about the LeafNode stuff. Is this something that could be
done by expression_tree_walker? I'm not completely familiar with it so
maybe there's some showstopper such as some node tags not being
supported, or maybe it just doesn't help. But I'm curious.
--
Álvaro Herrera
The Postg
On 2/29/12 3:53 PM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
Robert Haas writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
wrote:
The utility would run in the old cluster before upgrading, so the the flag
would have to be present
On Feb 29, 2012, at 6:02 PM, Bruce Momjian wrote:
> On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote:
>> On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian wrote:
>>> OK, I have implemented both Roberts and Àlvaro's ideas in my patch.
>>> I only add the .old suffix to pg_controldata when
Nathan Boley writes:
> On Wed, Feb 29, 2012 at 2:43 PM, Tom Lane wrote:
>> Nathan Boley writes:
>>> If I understand you're suggestion, queries of the form
>>> SELECT * FROM rel
>>> WHERE ARRAY[ 1,2,3,4 ] <= x
>>> AND x <=ARRAY[ 1, 2, 3, 1000];
>>> would no longer use an index. Is that corre
On Wed, Feb 29, 2012 at 2:43 PM, Tom Lane wrote:
> Nathan Boley writes:
>> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane wrote:
>>> I am starting to look at this patch now. I'm wondering exactly why the
>>> decision was made to continue storing btree-style statistics for arrays,
>>> in addition to
On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote:
> On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian wrote:
> > OK, I have implemented both Roberts and Àlvaro's ideas in my patch.
> > I only add the .old suffix to pg_controldata when link mode is used, and
> > I now do it after the schema
Robert Haas writes:
> On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane wrote:
>> I think you're just assuming that without any solid evidence. My point
>> is precisely that if the more-parameterized path *fails* to generate
>> fewer rows, we want add_path to notice that and throw it out (or at
>> least
Robert Haas writes:
> On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane wrote:
>> Easier for who? I don't care for the idea of code that has to cope with
>> two page formats, or before long N page formats, because if we don't
>> have some mechanism like this then we will never be able to decide that
>>
Nathan Boley writes:
> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane wrote:
>> I am starting to look at this patch now. I'm wondering exactly why the
>> decision was made to continue storing btree-style statistics for arrays,
>> in addition to the new stuff.
> If I understand you're suggestion, qu
On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>>> Indeed, and the code already knows that. However, in this example, path
>>> A is capable of dominating the other three (being strictly less
>>> parameterized than them)
On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane wrote:
> Alexander Korotkov writes:
>> On Mon, Jan 23, 2012 at 7:58 PM, Noah Misch wrote:
>>> I've attached a new version that includes the UINT64_FMT fix, some edits of
>>> your newest comments, and a rerun of pgindent on the new files. I see no
>>> o
>The most obvious thing to do about this is to consider that one path can
>dominate another on cost only if it is both cheaper *and* produces no
>more rows. But I'm concerned about the cost of inserting yet another
>test condition into add_path, which is slow enough already. Has anyone
>got an id
Hi all,
[Bcc'ed Tom Lane as he had done the initial investigation on this.]
Following up on the earlier discussions in
[1] http://archives.postgresql.org/pgsql-hackers/2010-11/msg01575.php
and
[2] http://archives.postgresql.org/pgsql-hackers/2011-08/msg00330.php
with an initial fix in
[3]
http:
On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
>> wrote:
>>> The utility would run in the old cluster before upgrading, so the the flag
>>> would have to be present in the old version. pg_upgrade would check that the
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
>
> Robert Haas writes:
> > On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
> > wrote:
> >> The utility would run in the old cluster before upgrading, so the the flag
> >> would have to be present in the old version. pg_upg
Robert Haas writes:
> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
> wrote:
>> The utility would run in the old cluster before upgrading, so the the flag
>> would have to be present in the old version. pg_upgrade would check that the
>> flag is set, refusing to upgrade if it isn't, with an
On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian wrote:
> OK, I have implemented both Roberts and Àlvaro's ideas in my patch.
> I only add the .old suffix to pg_controldata when link mode is used, and
> I now do it after the schema has been created (the most common failure
> case for pg_upgrade), an
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
wrote:
> On 29.02.2012 21:30, Robert Haas wrote:
>>
>> On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
>> wrote:
>>>
>>> Note that if we want such an utility to walk and transform pages, we
>>> probably need a marker in the catalogs somewhere s
Excerpts from Thom Brown's message of mié feb 29 17:50:14 -0300 2012:
> On 29 February 2012 20:33, Euler Taveira de Oliveira
> wrote:
> > On 29-02-2012 15:23, Thom Brown wrote:
> >> Or just change it to output a verbose notice without changing the syntax?
> >>
> > I can't see why we will do it o
On Wed, Feb 29, 2012 at 6:14 PM, Christopher Browne wrote:
> On Wed, Feb 29, 2012 at 11:14 AM, Simon Riggs wrote:
>> But it is very effective at avoiding 4 out of the 5 writes you mention.
>
> For the "common case," would we not want to have (1) [WAL] and (2)
> [Writing the pre-frozen tuple]?
>
>
On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Thu, Mar 1, 2012 at 12:39 AM, Tom Lane wrote:
> >> I am starting to look at this patch now. I'm wondering exactly why the
> >> decision was made to continue storing btree-style statistics for arrays,
>
> > Prob
Alexander Korotkov writes:
> On Thu, Mar 1, 2012 at 12:39 AM, Tom Lane wrote:
>> I am starting to look at this patch now. I'm wondering exactly why the
>> decision was made to continue storing btree-style statistics for arrays,
> Probably, btree statistics really does matter for some sort of ar
Peter Eisentraut writes:
> On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote:
>> Hm? Obviously I misunderstood what changes you were proposing to make,
>> so would you mind spelling it out?
> The details are to be determined, but a possible change would likely be
> that instead of looking for a
On Thu, Mar 1, 2012 at 12:39 AM, Tom Lane wrote:
> I am starting to look at this patch now. I'm wondering exactly why the
> decision was made to continue storing btree-style statistics for arrays,
> in addition to the new stuff. The pg_statistic rows for array columns
> tend to be unreasonably
On 29 February 2012 20:33, Euler Taveira de Oliveira wrote:
> On 29-02-2012 15:23, Thom Brown wrote:
>> Or just change it to output a verbose notice without changing the syntax?
>>
> I can't see why we will do it only for DROP OWNED. Chat messages are annoying
> unless the user asks for it (that's
Alexander Korotkov writes:
> On Mon, Jan 23, 2012 at 7:58 PM, Noah Misch wrote:
>> I've attached a new version that includes the UINT64_FMT fix, some edits of
>> your newest comments, and a rerun of pgindent on the new files. I see no
>> other issues precluding commit, so I am marking the patch
On 29-02-2012 15:23, Thom Brown wrote:
> Or just change it to output a verbose notice without changing the syntax?
>
I can't see why we will do it only for DROP OWNED. Chat messages are annoying
unless the user asks for it (that's why I suggested VERBOSE).
--
Euler Taveira de Oliveira - Timb
Hello
2012/2/29 Alvaro Herrera :
>
> I think the way we're passing down the options to the checker is a bit
> of a mess. The way it is formulated, it seems to me that we'd need to
> add support code in the core CheckFunction for each option we might want
> to accept in the PL-specific checkers --
Excerpts from Heikki Linnakangas's message of mié feb 29 16:29:26 -0300 2012:
> On 29.02.2012 21:18, Alvaro Herrera wrote:
> > Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300
> > 2012:
> >> I thought my view on how this should be done was already clear, but just
> >> in ca
On 02/29/2012 02:33 PM, Peter Eisentraut wrote:
On sön, 2011-05-08 at 19:35 -0400, Tom Lane wrote:
I believe that the "make check" target in src/test/isolation is
fundamentally unportable, as is illustrated by the fact that buildfarm
member coypu is currently choking on it. The reason is that
On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
> >> In particular, I observe that we get pushback anytime we break something
> >> in a way that makes SSL config files be required on the client side;
> >> see bug
On 29.02.2012 21:30, Robert Haas wrote:
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
wrote:
Note that if we want such an utility to walk and transform pages, we
probably need a marker in the catalogs somewhere so that pg_upgrade can
make sure that it was done in all candidate tables -- whic
On sön, 2011-05-08 at 19:35 -0400, Tom Lane wrote:
> I believe that the "make check" target in src/test/isolation is
> fundamentally unportable, as is illustrated by the fact that buildfarm
> member coypu is currently choking on it. The reason is that the
> pg_isolation_regress program depends on
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
wrote:
> Note that if we want such an utility to walk and transform pages, we
> probably need a marker in the catalogs somewhere so that pg_upgrade can
> make sure that it was done in all candidate tables -- which is something
> that we should get in
On 29.02.2012 21:18, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300 2012:
I thought my view on how this should be done was already clear, but just
in case it isn't, let me restate: Enlarge the page header to make room
for the checksum. To handle upg
On Wed, Feb 29, 2012 at 2:09 PM, Heikki Linnakangas
wrote:
> On 29.02.2012 19:54, Simon Riggs wrote:
>> I'm beginning to lose faith that objections are being raised at a
>> rational level. It's not a panel game with points for clever answers,
>> its an engineering debate about how to add features
Peter Eisentraut writes:
> On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
>> In particular, I observe that we get pushback anytime we break something
>> in a way that makes SSL config files be required on the client side;
>> see bug #6302 for most recent example.
> *If* we were to make a chan
On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote:
> In particular, I observe that we get pushback anytime we break something
> in a way that makes SSL config files be required on the client side;
> see bug #6302 for most recent example.
*If* we were to make a change in libpq analogous to the serv
Peter Eisentraut writes:
> On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
>> Yes, ignoring a missing file in a security context is definitely not good.
>> It should throw an error.
>>
>> We have a few bad defaults from the old days around SSL for this, but if it
>> requires breaking ba
Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300 2012:
> On 29.02.2012 19:54, Simon Riggs wrote:
> > I'm beginning to lose faith that objections are being raised at a
> > rational level. It's not a panel game with points for clever answers,
> > its an engineering debate abou
Excerpts from Heikki Linnakangas's message of jue ene 26 15:58:58 -0300 2012:
> On 26.01.2012 17:31, Tom Lane wrote:
> > The idea that occurs to me is to have the code that uses the GUC do a
> > verify_mbstr(noerror) on it, and silently ignore it if it doesn't pass
> > (maybe with a LOG message).
Robert Haas writes:
> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>> Indeed, and the code already knows that. However, in this example, path
>> A is capable of dominating the other three (being strictly less
>> parameterized than them), and B and C are each capable of dominating D.
>> The p
On 29.02.2012 19:54, Simon Riggs wrote:
I'm beginning to lose faith that objections are being raised at a
rational level. It's not a panel game with points for clever answers,
its an engineering debate about how to add features real users want.
And they do want, so let me solve the problems by ag
On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane wrote:
>> I am having trouble
>> constructing an example, but I feel like there might be cases where
>> it's possible to have path A, not parameterized, path B, parameterized
>> by R, and path C, parameterized by S, and maybe also path D,
>> parameterized
I think the way we're passing down the options to the checker is a bit
of a mess. The way it is formulated, it seems to me that we'd need to
add support code in the core CheckFunction for each option we might want
to accept in the PL-specific checkers -- including what type of value
the option re
Robert Haas writes:
> On Tue, Feb 28, 2012 at 5:35 PM, Tom Lane wrote:
>> The most obvious thing to do about this is to consider that one path can
>> dominate another on cost only if it is both cheaper *and* produces no
>> more rows.
> Hmm. Are you sure that's the right rule?
On further reflec
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote:
> > I'm still worried about this. If we ignore a missing root.crt, then the
> > effect is that authentication and certificate verification might fail,
> > which would be annoying, but you'd notice it soon enough. But if we
> > ignore a mis
On Wed, Feb 29, 2012 at 12:20 PM, Thom Brown wrote:
> On 29 February 2012 17:16, Tom Lane wrote:
>> Thom Brown writes:
>>> So could we introduce either a command to show which objects are owned
>>> by a particular role, or allow a dry-run of DROP OWNED BY?
>>
>> It's always been possible to do t
On 29 February 2012 18:15, Euler Taveira de Oliveira wrote:
> On 29-02-2012 14:20, Thom Brown wrote:
>> No, the cascade part is fine. It's the objects which won't cause a
>> cascade that are an issue. Putting it in a transaction for rolling
>> back doesn't help find out what it intends to drop.
On 29-02-2012 14:20, Thom Brown wrote:
> No, the cascade part is fine. It's the objects which won't cause a
> cascade that are an issue. Putting it in a transaction for rolling
> back doesn't help find out what it intends to drop.
>
DROP OWNED BY foo VERBOSE?
--
Euler Taveira de Oliveira -
On Wed, Feb 29, 2012 at 11:14 AM, Simon Riggs wrote:
> But it is very effective at avoiding 4 out of the 5 writes you mention.
For the "common case," would we not want to have (1) [WAL] and (2)
[Writing the pre-frozen tuple]?
If we only write the tuple (2), and don't capture WAL, then the COPY
w
On Tue, Feb 28, 2012 at 5:35 PM, Tom Lane wrote:
> The most obvious thing to do about this is to consider that one path can
> dominate another on cost only if it is both cheaper *and* produces no
> more rows.
Hmm. Are you sure that's the right rule? I am having trouble
constructing an example,
On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
>> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
>> wrote:
>>
Are you saying you would accept the patch if we had this?
>>
>>> I think I would still be uncomfortable with the hac
On Wed, Feb 29, 2012 at 5:44 PM, Robert Haas wrote:
>>> You have comments from three different people, all experienced
>>> hackers, disagreeing with this position;
>>
>> Who is the third person you speak of? Perhaps they will speak again if
>> they wish to be heard.
>
> Tom Lane. It was the very
On Wed, Feb 29, 2012 at 12:26 PM, Simon Riggs wrote:
> On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas wrote:
>> On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
>>> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
>>> wrote:
>>>
> Are you saying you would accept the patch if we had thi
On 29 February 2012 17:16, Tom Lane wrote:
> Thom Brown writes:
>> So could we introduce either a command to show which objects are owned
>> by a particular role, or allow a dry-run of DROP OWNED BY?
>
> It's always been possible to do that:
>
> begin;
> drop owned by joe;
>
Thom Brown writes:
> So could we introduce either a command to show which objects are owned
> by a particular role, or allow a dry-run of DROP OWNED BY?
It's always been possible to do that:
begin;
drop owned by joe;
rollback;
I believe this is already the recommended ap
Hi all,
If someone wants to drop objects owned by a particular role, they'll
use DROP OWNED BY role. However, the implications of this statement
aren't easily known, and once you've run it, it's not communicated
which objects were dropped.
So could we introduce either a command to show which obj
On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
> wrote:
>
>>> Are you saying you would accept the patch if we had this?
>
>> I think I would still be uncomfortable with the hacks in the page header.
>
> There are no "hacks". There are so
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
wrote:
>> Are you saying you would accept the patch if we had this?
> I think I would still be uncomfortable with the hacks in the page header.
There are no "hacks". There are some carefully designed changes with
input from multiple people, in
On Sat, Feb 25, 2012 at 6:58 PM, Simon Riggs wrote:
> On Sat, Feb 25, 2012 at 6:24 PM, Kevin Grittner
> wrote:
>> Simon Riggs wrote:
>>
>>> This patch extends that and actually sets the tuple header flag as
>>> HEAP_XMIN_COMMITTED during the load.
>>
>> Fantastic!
> I think we could add that as
On Mon, Feb 27, 2012 at 11:54 PM, Andrea Suisani wrote:
> On 02/28/2012 04:52 AM, Rob Wultsch wrote:
>>
>> On Wed, Feb 22, 2012 at 2:31 PM, james
>> wrote:
>>>
>>> Has anyone considered managing a system like the DragonFLY swapcache for
>>> a
>>> DBMS like PostgreSQL?
>>>
>>
>> https://www.facebo
On 29.02.2012 17:42, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
wrote:
Surely it can be done online. You'll just need a third state between off and
on, where checksums are written but not verified, while the cluster is
scanned.
Are you saying you would accept the
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
wrote:
> Surely it can be done online. You'll just need a third state between off and
> on, where checksums are written but not verified, while the cluster is
> scanned.
Are you saying you would accept the patch if we had this?
--
Simon Rigg
Shigeru Hanada writes:
> How about removing postgresql_fdw_validator from backend binary, and
> changing dblink to use contrib/postgresql_fdw's validator? It breaks
> some backward compatibility and requires contrib/postgresql_fdw to be
> installed before using contrib/dblink with foreign servers
On 29.02.2012 17:01, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
wrote:
On 22.02.2012 14:30, Simon Riggs wrote:
Agreed. No reason to change a checksum unless we rewrite the block, no
matter whether page_checksums is on or off.
This can happen:
1. checksums are i
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
wrote:
> On 22.02.2012 14:30, Simon Riggs wrote:
>>
>> On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch wrote:
>>>
>>> On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's n
Heikki Linnakangas wrote:
> On 23.02.2012 01:36, Jeff Davis wrote:
>> On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote:
>>> Hmm, it occurs to me if we have to abort a transaction due to
>>> serialization failure involving a prepared transaction, we might
>>> want to include the prepared transa
On 22.02.2012 14:30, Simon Riggs wrote:
On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch wrote:
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's no
particularly easy way to know that your whole cluster has checksums.
No matter h
On 23.02.2012 01:36, Jeff Davis wrote:
On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote:
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 14.02.2012 04:57, Dan Ports wrote:
The easiest answer would be to just treat every prepared
transaction foun
Hello
2012/2/28 Alvaro Herrera :
>
>
> In gram.y we have a new check_option_list nonterminal. This is mostly
> identical to explain_option_list, except that the option args do not
> take a NumericOnly (only opt_boolean_or_string and empty). I wonder if
> it's really worthwhile having a bunch of
Hi,
In streaming replication, after failover, new master might have lots
of un-applied
WAL files with old timeline ID. They are the WAL files which were recycled as a
future ones when the server was running as a standby. Since they will never be
used later, they don't need to be archived after fai
2012/2/29 Shigeru Hanada :
> (2012/02/29 4:07), Peter Eisentraut wrote:
>> Let's at least be clear about the reasons here. The fact that
>> postgresql_fdw_validator exists means (a) there is a possible naming
>> conflict that has not been discussed yet, and/or (b) the name is already
>> settled an
(2012/02/29 4:07), Peter Eisentraut wrote:
> Let's at least be clear about the reasons here. The fact that
> postgresql_fdw_validator exists means (a) there is a possible naming
> conflict that has not been discussed yet, and/or (b) the name is already
> settled and we need to think of a way to ma
On 02/28/2012 08:54 AM, Andrea Suisani wrote:
On 02/28/2012 04:52 AM, Rob Wultsch wrote:
On Wed, Feb 22, 2012 at 2:31 PM, james wrote:
Has anyone considered managing a system like the DragonFLY swapcache for a
DBMS like PostgreSQL?
https://www.facebook.com/note.php?note_id=388112370932
in
On Mon, Feb 27, 2012 at 4:26 AM, Peter Geoghegan wrote:
> This does not appear to have any user-visible effect on caret position
> for all variations in coercion syntax, while giving me everything that
> I need. I had assumed that we were relying on things being this way,
> but apparently this is
On Tue, Feb 28, 2012 at 10:35 PM, Tom Lane wrote:
> The flaw in this logic, of course, is that the seqscan might be cheaper
> than the parameterized indexscan, but *it produces a whole lot more
> rows*, meaning that any subsequent join will be a lot more expensive.
> Previously add_path didn't ha
80 matches
Mail list logo
